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Jl6.  Abstract 

This  report  describes  the  work  effort  and  results  of  a feasibility  and  desirability 
study  of  replacing  simulator  pilot  consoles  in  the  field  with  more  cost  effective, 
easier  to  learn  and  use  devices.  Technically,  such  an  action  was  found  to  be 
feasible  and  could  result  in  a significantly  improved  simulator  pilot  operating 
capability.  A touch  panel  input  device  using  a menu  list  concept  with  target  to 
map  association,  performed  by  an  interface  processor,  is  recommended.  As  an  aid  to 
deciding  the  desirability  of  proceeding  with  such  a procurement,  the  costs  of 
various  alternatives  were  estimated.  The  costs  of  the  preferred  system  was  found 
to  exceed  the  budget,  unless  a reduced  number  of  consoles  of  sites  were  equipped, 
in  which  case  the  average  cost  per  console  was  increased  substantially.  The  infor- 
mation from  field  input  was  logically  analyzed  to  arrive  at  the  conclusion  that  the 
limited  life  potential  of  the  system,  the  operational  limits  on  increased  training, 
and  high  overall  cost  make  the  desirability  of  the  action  questionable. 


17.  Key  Words 

Simulator  Pilot  Consoles  DYSIM/ETG 
ATCS  Training  NAS  Enroute  ARTS  III 
Touch  Panel  Menu  List 


18.  Distribution  Statement 

Document  is.  available  to  the  public 
through  the  National  Technical  Information 
Service,  Springfield,  Virginia  22151 


19.  Security  Classif.  (of  this  report) 

20.  Security  Clossif.  (of  this  page) 

21*  No.  of  Pages 

Unclassified 

Unclassified 

104 

Form  DOT  F 1700.7  (8-72) 


Reproduction  of  completed  page  authorized 


PREFACE 


The  conduct  of  this  study  and  the  preparation  of  this  report  required  the  help 
and  assistance  of  several  organizations  and  individuals.  The  authors  gratefully 
acknowledge  the  special  contribution  of  Messrs.  R.  A.  Bales,  M.  M.  Lawrence, 
and  R.  H.  Watson  of  MITRE  Corporation,  Metrek  Division,  who  performed  the 
significant  interface  analysis  portion  of  the  study,  contributed  major  input  to 
the  costing  analysis,  and  prepared  the  portions  of  the  functional  specifica- 
tions required  under  this  project.  The  authors  are  also  indebted  to  Messrs. 

R.  M.  Johns  and  R.  F.  Irwin  of  the  Development  Programming  Branch,  ARD-140, 
personnel  of  the  National  Enroute  Data  Systems  Branch,  AAT-540,  and  National 
Terminal  Data  Systems  Branch,  AAT-550,  who  provided  valuable  advice  in  the 
software  analysis,  and  Messrs.  F.  B.  Woodson  and  W.  J.  Dunn,  ANA-230,  who  acted 
as  engineering  consultants  on  this  project. 


./ 


u 

oik: 


: ;t;  ssses  J 

/or  SPECIAL 


TABLE  OF  CONTENTS 


Page 


INTRODUCTION  1 

Background  1 
Objective  1 
Scope  2 
Feasibility  and  Desirability  2 
Technical  Approach  Overview  4 

FUNCTIONAL  ANALYSIS  5 

Approach  5 
Field  Training  Systems  5 
Simulator  Pilot  Position  7 

DEVICE  ANALYSIS  11 

Approach  11 
Entry  Device  Investigation  12 
Touch  Entry  Concept  Evaluation  13 
Display  Investigation  14 
Tabular  Versus  Graphic  Requirements  16 

INTERFACE  ANALYSIS  17 

Approach  17 
Enroute  Facilities  ' 18 
Terminal  Facilities  22 
Other  Interface  Alternatives  25 

SOFTWARE  ANALYSIS  25 

Approach  25 
Basic  Enroute  Software  Impact  26 
Basic  ARTS  Software  Impact  27 
Target /Map  Association  23 
Increased  Training  Capability  28 
Maintaining  Software  Compatibility  29 

COST  ANALYSIS  30 

Approach  30 
Basic  Costs  of  Enroute  Interface  Alternatives  31 
Basic  Costs  of  ARTS  III  Interface  Alternatives  31 
Cost  Savings  Using  DARC  and  Tabular  Displays  37 
Adjusted  Final  Cost  Estimates  37 
Future  Utilization  of  Pilot  Consoles  42 


v 


TABLE  OF  CONTENTS  (Continued) 


Page 

FUNCTIONAL  SPECIFICATION 

42 

CONCLUSIONS 

45 

RECOMMENDATIONS 

47 

REFERENCES 

48 

APPENDICES 

A - AAD-1  letter  to  AED-1,  Assistance  Required  in  the  Development 
of  ATCS  Training,  dated  July  14,  1975 

B - Letter  Report,  NA-76-43-LR,  Low-Cost  ATCS  Training  Pilot 

Simulator  Console  for  Field  Facilities,  dated  August  26,  1976 

C - ARD-152  letter  to  AAT-14.2,  APT-310,  AAF-610  and  ANA-230, 

Simulator  Pilot  Consoles  for  Enroute  and  ARTS  III  ATC  Facilities, 
dated  August  24,  1976 

D - Comparison  of  DYSIM  and  ETG  Simulator  Pilot  Functions 

E - Data  Entry  Concept  Display 

F - Entry  Concept  Evaluation  Questionnaire  Responses 

G - AAF-600  letter  to  ARD-100,  Use  of  the  DARC  Processor  with 
Pilot  Response  Units,  dated  January  24,  1977 

GLOSSARY 


vi 


1 


LIST  OF  ILLUSTRATIONS 

Figure  Page 

1 

2 

3 

4 

5 


Enroute  Interface  Approach  1:  Interface  the  Simulator  19 

Pilot  Consoles  with  the  CDC  or  DCC  Display  Subsystems 

Enroute  Interface  Approach  2:  Interface  the  Simulator  20 

Pilot  Consoles  with  the  CCC 

Enroute  Interface  Approach  3:  Interface  the  Simulator  21 

Pilot  Consoles  with  the  CD  Adapter 

ARTS  Interface  Approach  1:  Interface  the  Simulator  Pilot  23 
Console  with  the  MDBM  in  ARTS  III-A  and  with  the  I0P  in 
ARTS  III 

ARTS  Interface  Approach  2:  Interface  the  Simulator  Pilot  24 
Consoles  with  the  I0P  and  I0P-B 


LIST  OF  TABLES 


Table  Page 

1 Comparison  of  Candidate  Displays  for  Simulator  Pilot  15 

Console  Function 

2 Estimated  Costs  of  Enroute  Interface  Approach  1:  32 

Interface  Raytheon  Pilot  Console  with  the  CDC/DCC 

3 Estimated  Costs  of  Enroute  Interface  Approach  2:  33 

Interface  Pilot  Consoles  with  the  CCC 

A Estimated  Costs  of  Enroute  Interface  Approach  3:  3A 

Interface  Pilot  Consoles  with  the  CD  Adapter  to 
Generate  Simulated  Targets  External  to  the  CCC 

5 Estimated  Costs  of  ARTS  Interface  Approach  1:  35 

Interface  Pilot  Consoles  with  the  MDBM  in  ARTS  III-A 
and  Directly  with  the  IOP  in  Basic  ARTS  III 

6 nated  Costs  of  ARTS  Interface  Approach  2:  36 

rface  Pilot  Consoles  Directly  with  the  IOP  in 
ARTS  III-A  and  Basic  ARTS  III 

7 st  Comparison  of  Enroute  CCC  Interface  Approach  with  38 

DARC  and  Tabular  Display  Options 

8 Enroute  Sim  Pilot  Consoles  CCC  Interface  - Both  Graphic  39 

and  Tabular  Displays 

9 ARTS  III  and  ARTS  III-A  Sim  Pilot  Consoles,  IOP  or  IOP-B  AO 

Interface  - Both  Graphic  and  Tabular  Displays 

10  Cost  Comparison  of  Various  Combinations  of  Simulator  A1 

Pilot  Consoles  and  Enroute  Sites 

11  Cost  Comparison  of  Various  Combinations  of  Simulator  Pilot  A1 

Consoles  and  ARTS  III  Sites 


viii 


INTRODUCTION 


BACKGROUND. 

The  Federal  Aviation  Administration's  (FAA)  newly  upgraded  Air  Traffic  Control 
Specialist  (ATCS)  training  program  stipulates  that  after  graduation  from  the 
academy,  the  developmental  controller  will  receive  advanced  environmentally 
oriented  radar  training  at  the  Air  Traffic  Control  (ATC)  facility.  This 
requirement  will  be  satisfied  using  the  recently  improved  radar  controller 
training  capability  in  the  enroute  centers  and  the  Automated  Radar  Terminal 
System  (ARTS  III)  facilities.  The  training  function  in  the  enroute  centers 
is  provided  by  a training  simulation  computer  program  called  Dynamic  Simulation 
(DYSIM)  that  is  an  integral  part  of  the  operational  program  in  the  Central 
Computer  Complex  (CCC)  of  the  Air  Route  Traffic  Control  Center  (ARTCC)  system. 
Simulated  targets  are  generated  by  the  DYSIM  subprogram  of  the  CCC.  All  other 
automated  operational  functions,  such  as  tracking  and  strip  printing,  for  these 
simulated  aircraft,  are  performed  by  the  operational  subprograms  of  the  CCC. 

The  major  inputs  to  DYSIM  for  controlling  the  generation  of  radar  target  data 
are  provided  through  the  pilot  consoles.  The  simulator  pilot  responds  to  the 
trainee  controller's  instructions  to  "fly"  the  simulated  radar  targets.  The 
present  training  capability  in  the  enroute  centers  uses  operational  Plan  View 
Displays  (PVD)  for  both  the  trainee  and  pilot  positions. 

The  simulator  training  function  in  an  ARTS  III  facility  is  similar  to  the  DYSIM 
program  in  the  enroute  system.  The  simulation  computer  program.  Enhanced  Target 
Generator  (ETG)  is  an  integral  part  of  the  operational  program  in  the  ARTS  III 
Input/Output  Processor  (IOP) . As  in  the  enroute  system,  training  is  performed 
on  operational  displays  called  Data  Entry  and  Display  Systems  (DEDS) . At  the 
ARTS  III  locations,  however,  the  pilots  share  the  radar  display  with  the  ATCS 
trainee,  and  a separate  keyboard  is  provided  for  use  by  the  'simulator  pilot. 

The  operational  PVD's  and  DEDS  consoles  are  expensive  (in  excess  of  $110,000 
each)  but  provide  much  more  display  capability  than  is  needed  for  the  simulator 
pilot  position.  The  operational  need  for  these  consoles  is  great.  The  key- 
boards of  these  controller  consoles  are  not  designed  for  simulator  pilot  "flying" 
and,  therefore,  a high  rate  of  input  errors  have  been  reported.  The  capability 
for  fast  entry  is  limited  until  considerable  experience  is  attained. 

OBJECTIVE. 

The  objectives  of  this  project,  as  stated  in  the  Engineering  and  Development 
(E&D)  Program  Plan  (reference  1)  are: 

1.  To  investigate  the  feasibility  and  desirability  of  replacing  the  existing 
operational  consoles  (those  used  at  pilot  positions  in  field  training)  with  a 
more  cost  effective  pilot  simulator  type  console. 

2.  To  provide  technical  specifications  and  support  during  the  acquisition  of 
pilot  simulator  consoles,  if  required. 
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SCOPE. 


In  July  1975,  the  Associate  Administrator  for  Engineering  and  Development  (AED-1) 
received  a request  from  the  Associate  Administrator  for  Administration  (AAD-1) 
for  support  in  the  development  of  a revised  terminal/enroute  training  program 
(appendix  A),  including  the  development  of  engineering  specifications  for 
simulator  pilot  consoles.  The  resulting  E&D  program  plan  called  for  a feasi- 
bility and  desirability  study  as  stated  in  the  objective  and  further  stated 
that:  "If  the  study  demonstrates  the  practicality  of  introducting  new  pilot 
positions  in  either  or  both  systems,  then  technical  specifications  for  procure- 
ment of  simulator  pilot  consoles  will  be  developed  as  required  by  the  operating 
services. " 

As  a first  effort,  an  investigation  was  requested  of  the  possibility  of  pro- 
viding a low  cost,  quick  solution,  such  as  using  closed-circuit  television,  or 
a slaved  display,  to  provide  the  simulator  pilot  with  a picture  of  the  trainee's 
display.  This  was  performed  and  found  to  be  infeasible  as  reported  in  NAFEC 
Letter  Report,  NA-76-43-LR  (appendix  B) . 

Additional  guidelines  were  prepared  by  the  Systems  Research  and  Development 
Service  (SRDS)  Program  Manager  and  approved  by  representatives  of  the  Office 
of  Personnel  and  Training  (OPT),  Air  Traffic  Service  (ATS),  Airways  Facilities 
Service  (AFS) , and  SRDS  (appendix  C) . In  addition,  ATS  and  AFS  advised  that 
the  fiscal  year  1978  budget  provided  for  about  $3.7  million  for  114  consoles  at 
20  ARTCC's  in  the  continental  United  States,  NAFEC,  and  centers  external  to  the 
continent  equipped  with  Enroute  Automated  Radar  Tracking  Systems  (EARTS).  They 
also  advised  that  tentative  plans  were  being  made  for  a fiscal  year  1979  budget 
of  about  $4.6  million  for  consoles  at  ARTS  Ill-equipped  terminals. 

The  guidelines  required  that  a functional  specification  was  to  be  completed 
by  April  1,  1977,  in  order  to  make  the  desired  procurement  in  fical  year  1978. 
This  resulted  in  a change  in  emphasis  from  the  complete  system-wide  study 
originally  envisioned  (but  not  possible  in  the  time  allowed)  to  the  preparation 
of  the  specification  and  the  accumulation  of  data  necessary  to  support  that 
effort. 

The  resulting  accumulated  data,  with  conclusions  and  recommendations  regarding 
feasibility  and  desirability,  were  presented  to  a steering  group  consisting  of 
representatives  of  OPT,  ATS,  AFS,  and  SRDS  prior  to  the  delivery  of  the 
specifications,  as  planned,  to  allow  a decision  to  be  made  on  whether  to  pro- 
ceed with  the  procurement.  This  report  documents  the  effort  as  presented 
to  this  group  on  March  9,  1977. 

FEASIBILITY  AND  DESIRABILITY. 

The  question  of  the  feasibility  of  replacing  simulator  pilot  consoles  is 
primarily  a question  regarding  ability.  That  is:  Is  it  technically  possible 
and  cost  effective  to  replace  the  existing  operational-type  consoles,  used  in 
the  field  at  simulator  pilot  positions,  with  simpler,  lower  cost,  special  pur- 
pose devices  following  the  guidelines  (appendix  C)? 
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Desirability,  on  the  other  hand,  is  a question  of  practicality  and  benefit. 

That  is:  Is  it  practical  and  sufficiently  beneficial  to  replace  the  existing 
operational-type  consoles?  We  will  attempt  to  answer  the  feasibility  question, 
and  provide  sufficient  information  to  permit  a steering  group  decision  on  the 
desirability  of  proceeding  with  a fiscal  year  1978  procurement  based  on  the 
information  available. 

An  answer  to  the  feasibility  question  can  be  an  absolute  Yes  or  No.  However, 
an  answer  to  the  desirability  question  requires  knowledge  of  the  alternatives. 
The  basic  alternative,  of  course,  is  to  leave  the  system  as  it  is,  at  least  for 
awhile.  The  impact  of  that  alternative  should  start  with  an  understanding  of 
why  new  consoles  were  proposed  in  the  first  place.  The  Program  Plan  (refer- 
ence 1)  states  (in  reference  to  the  operational  controller  coi soles)  that:  "The 
cost  of  these  consoles  is  high;  their  keyboards  are  not  designed  for  simulator 
pilot  flying;  and  the  operational  need  for  consoles  is  great,"  implying  that 
new  simulator  pilot  consoles  are  needed  to  restore  the  costly  controller  con- 
soles to  operational  use.  Upon  investigation,  we  found  that  this  was  not  really 
the  purpose.  First,  as  stated  earlier  in  the  background  statement:  "At  ARTS  III 
locations,  the  pilots  share  the  radar  display  with  the  ATCS  trainee."  That  is 
(as  was  verified  by  observation),  in  most  cases,  a separate  console  is  not  used 
by  the  simulator  pilots  at  ARTS  III  facilities.  Any  new  consoles  wou. i be 
additions  to  the  system,  which  would  have  the  benefit  of  allowing  separation  of 
the  students  and  pilots  while  expanding  their  capability,  but,  gener  . lly,  they 
will  not  replace  controller  consoles. 

Further,  it  was  also  found  that  AFS  requested  that  all  facilities  (ARTS  III 
and  enroute)  report  the  total  number  of  operational  displays  necessary  to  meet 
their  needs,  including  training,  through  1982.  The  resulting  shortage  of 
enroute  consoles  is  to  be  relieved  by  another  procurement  budgeted  in  fiscal 
year  1978.  A procurement  to  meet  the  ARTS  III  shortage  is  also  planned.  The 
AFS  request  and  field  response  did  not  consider  the  possibility  that  simulator 
pilot  consoles  used  for  training  might  be  replaced  by  new  equipment.  Therefore, 
all  controller  consoles  presently  used  for  simulator  pilots  (plus  possibly 
others  for  projected  needs)  are  planned  to  be  retained  for  training  purposes. 

The  objective  apparently  is  to  permit  all  of  these  consoles  to  be  used  for 
students  if  replacement  simulator  pilot  consoles  are  purchased  as  a result  of 
this  project.  Presently,  the  largest  enroute  training  capability  has  four 
student  and  four  simulator  pilot  positions.  The  guidelines  (appendix  C) 
require  a maximum  of  eight  student  positions,  thus  supporting  the  assumption 
that  a doubling  of  enroute  training  capacity  is  desired. 

We  have  concluded,  therefore,  that  the  actual  purpose  for  obtaining  replace- 
ment simulator  pilot  consoles  is  to  enhance  and  expand  the  training  capability 
and  improve  (simplify)  entries  without  the  high  cost  or  purchasing  additional 
operational  consoles. 

The  alternative  to  providing  replacement  simulator  pilot  consoles,  which  we 
must  investigate,  is  the  impact  of  not  providing  these  improvements.  The  total 
impact  of  that  alternative  can  be  fully  determined  only  by  a complete  study  of 
the  present  system,  its  utilization,  life,  and  projected  training  needs.  This 
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type  of  study  was  specifically  rejected  because  of  insufficient  time.  We  will, 
however,  attempt  to  answer  the  desirability  question  by  a logical  analysis  of 
the  data  available,  including  other  factors  affecting  (and  affected  by)  the 
significant  increase  in  training  capacity  indicated.  A following  project  will 
undertake  a full  study  of  the  present  radar  training  capabilities  in  the  field, 
and  develop  requested  improvements  to  the  DYSIM  and  ETG  simulation  programs. 

TECHNICAL  APPROACH  OVERVIEW. 

As  originally  planned,  the  effort  was  broken  into  five  phases:  (1)  Functional 
and  Software  Analysis,  (2)  Interface  Analysis,  (3)  Console  Design  and  Human 
Engineering,  (4)  Candidate  Screening  and  Reporting,  and  (5)  Specification 
Documentation.  It  was  quickly  recognized  that  the  primary  efforts  would  be 
the  functional  analysis  portion  of  Phase  1 and  the  interface  analysis  (Phase  2). 
All  other  actions  would  be  a support  to,  or  an  outgrowth  of,  the  results  of 
these  analyses. 

The  design  guidelines  were  treated  as  guidelines  only,  and  not  as  firm  restric- 
tions, especially  in  the  area  of  limitations  on  any  hardware  and  software 
modif ications.  It  was  recognized  that,  when  a new  device  is  introduced  into 
existing  automated  systems,  some  impact  on  the  existing  system  is  unavoidable. 
Modifications  were  also  anticipated  if  an  interface,  different  from  that  used 
by  the  replaced  devices,  is  required.  Also,  in  order  to  take  a responsible 
approach  to  the  problem,  it  was  essential  that  the  requirements  be  considered 
against  the  total  combined  capabilities  of  both  the  existing  system  and  the 
proposed  new  subsystem.  Tradeoffs  were  investigated,  which  could  result  in 
more  efficient  use  of  the  total  capability.  Other  things  considered  were  the 
future  utility  of  the  new  subsystem  in  light  of  the  long-term  training  needs 
and  anticipated  system  changes,  and  the  commonality  of  the  new  subsystem  with 
other  auxiliary  displays  under  development. 

Data  accumulated  from  field  trips  and  other  contacts  with  field  personnel  were 
used  primarily  to  provide  the  specific  information  needed  for  completing  the 
functional  specifications  by  April  1,  1977.  An  attempt  was  made  to  observe 
the  total  training  environment  and  to  question  users  regarding  it.  Time  did 
not  permit  an  organized  study  of  a sufficient  sample  size  and  length  to  provide 
statistical  support  to  the  general  impressions,  and  the  sometimes  very  subjec- 
tive information  received.  The  results,  therefore,  reflect  a broad  analysis  of 
our  observations  and  information  received,  as  they  relate  to  the  questions 
regarding  feasibility,  desirability,  and  to  the  training  systems  in  general. 

As  requested,  an  interim  briefing  on  the  preliminary  findings  was  presented 
midway  through  the  effort.  Also,  a final  oral  report  on  the  information  con- 
tained in  this  report  was  presented  on  March  9,  1977,  to  allow  the  interservice 
steering  group  to  decide  on  the  advisability  of  proceeding  with  the  fiscal 
year  1978  procurement. 
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FUNCTIONAL  ANALYSIS 


APPROACH. 

An  analysis  of  radar  simulation  training  as  it  is  conducted  in  the  field  facil- 
ities was  carried  out  to  obtain  a full  understanding  of  the  functions  required 
of  the  simulator  pilot.  As  a first  step,  current  available  documentation  on 
DYSIM  and  ETG  was  obtained  and  studied.  NAS  Change  Proposals  (NCP)  depicting 
change.,  to  the  basic  capabilities  were  analyzed.  A function-by-function  com- 
parison of  DYSIM  and  ETG  was  prepared.  From  this,  the  common  and  unique  capa- 
bilities of  the  two  subprograms  were  examined  and  the  amount  and  complexity 
of  button-pushing  required  for  particular  entries  was  determined. 

Visits  were  made  to  ARTS  III  and  enroute  facilities  that  were  actively  con- 
ducting radar  simulation  training  programs.  Radar  simulation  training  sessions 
were  observed,  with  particular  attention  paid  to  the  simulator  pilot  function. 

In  each  instance,  radar  simulation  was  discussed  at  length  with  the  facility's 
Evaluation  and  Proficiency  Development  Officers  (EPDO)  and  Specilists  (EPDS). 
Subjects  covered  in  these  discussions  included:  overall  utilization  of  radar 
simulation  and  its  effectiveness,  performance  of  the  pilot  function  and 
associated  problems,  and  problems  associated  with  radar  simulation  in  general. 

Facilities  visited  or  represented  via  direct  interview  with  EPDS  included: 

New  York,  Chicago,  Washington,  Cleveland,  Albuquerque,  and  Atlanta  ARTCC's; 
and  Philadelphia,  Baltimore,  Chicago,  Dallas,  Cleveland,  Rale igh-Dur ham  and 
Boston  Terminal  Radar  Approach  Control  (TRACON)  facilities. 

Based  on  the  information  gathered  during  field  trips,  the  various  clearances 
and  other  information  received  by  the  simulator  pilot  were  analyzed  as  to  source, 
resulting  actions  necessary,  methods  of  accomplishing  those  actions,  and 
associated  problems.  This  of  course  led  to  more  discussions  and  analyses  of 
the  training,  the  training  environment,  and  testing  at  the  various  sites. 

FIELD  TRAINING  SYSTEMS. 

GENERAL.  Preliminary  investigations  conducted  to  determine  operational  require- 
ments, although  limited,  revealed  some  findings  that  were  considered  to  be 
normative,  with  variations  between  facilities  and  personnel.  Although  train- 
ing requirements  are  well  established  for  all  facilities,  there  appears  to  be 
a wide  variation  between  the  training  needs  (space,  equipment,  and  staffing) 
and  their  ability  to  meet  those  needs. 

TRAINING  ENVIRONMENT.  Radar  simulation  training  laboratories  have  not  yet  been 
established  at  some  facilities;  notably  terminals,  and  space  for  such  labora- 
tories is  nonexistent  at  some  locations.  Training  at  some  terminals  is  done 
in  the  maintenance  room  using  the  maintenance  display,  while  other  facilities 
have  first-class  training  environments.  Space  limitations  would  prevent  any 
significant  expansion  of  the  training  laboratories  at  many  facilities  (both 
terminals  and  centers). 
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COMMUNICATIONS . One  area  of  concern  frequently  mentioned  was  the  lack  of 
realism  in  the  communications  system  used  In  the  training  laboratory.  The 
Bell  300  communications  system  is  used  in  only  a few  facilities  and  apparently 
the  cost  of  including  it  in  others  is  prohibitive.  Terminal  training  staffs 
complain  that  the  ’rainee  issues  his  control  instructions  "into  thin  air," 
robbing  significant  realism  from  the  simulation.  A leased  communications 
package  for  DYSIM  laboratories  that  do  not  have  the  Bell  300  system  is  being 
provided  to  relieve  this  problem  in  centers. 

STAFFIilG.  Staffing  in  terminal  facilities  varies  from  a single  EPDS  who  acts 
as  pilot,  ghost,  instructor,  and  evaluator,  to  facilities  with  hired  target 
generator  operators,  an  EPDO,  and  teams  of  EPDS's  supported  by  Data  Systems 
Specialists  (DSS) . As  might  be  expected,  variations  in  the  degree  to  which 
simulation  is  used  appear  to  be  proportional  to  the  equipment  and  staffing 
variations.  It  is  probably  highly  significant  that  terminals  that  are  ARTS  III 
assembly  sites  seem  to  be  the  most  advanced  in  ETG  implementation.  The  variance 
between  enroute  facilities  is  not  as  great  as  between  terminals,  yet  variances 
do  exist.  The  most  apparent  difference  is  that  the  larger  centers  seem  to  be 
better  staffed,  and  as  a result  are  more  advanced  in  DYSIM  implementation  than 
the  smeller  centers. 

In  centers,  it  is  common  to  use  two  instructors  in  one  problem.  One  instructor 
monitors  and  evaluates  the  trainee's  performance  while  the  other  instructor 
monitors  the  problem  from  the  pilot  positions  and  modifies  the  developing  sit- 
uation as  necessary  to  meet  the  training  requirements.  Availability  of  personnel 
properly  trained  and  currently  proficient  in  the  simulator  pilot  function 
influence  the  training  program.  In  DYSIM,  two  pilots  ordinarily  handle  a 
50  percent  traffic  sample;  three  pilots  are  needed  for  a higher  density  traffic 
sample.  In  ETG  also,  up  to  three  pilots  may  be  required  to  support  one  con- 
troller. If  fewer  are  used,  a pilot  can  fall  behind  in  his  data  entries  and 
adversely  affect  the  controller's  performance.  Training  staffs  are  under- 
standably reluctant  to  administer  pass/fail  tests  under  such  circumstances. 

UTILIZATION.  In  the  centers,  DYSIM  is  viewed  enthusiastically  and  is  widely 
accepted  by  management,  training  staff,  and  controllers  alike.  These  people 
feel  that  considerable  improvement  in  the  quality  of  training  and  significant 
reduction  in  the  total  amount  of  training  required,  including  on-the-j ob-train- 
ing  (OJT) , has  resulted  from  the  use  of  DYSIM.  Measurements  of  these  factors 
are  not  available,  and  judgments  as  to  amounts  vary  widely.  DYSIM  is  utilized 
heavily,  about  16  hours  a day  in  some  facilities,  and  its  use  extends  well 
beyond  merely  training  developmental  controller0.  It  is  also  used  for  pro- 
ficiency checks,  remedial  or  refresher  training  and  testing,  training  for 
special  or  unusual  situations,  staff  and  region  familiarization,  and  for  evalu- 
ating new  procedures  or  traffic  flow  changes.  Terminal  facilities  also  are 
enthusiastic  about  the  benefits  of  radar  simulation  for  training.  It  is  thought 
of  as  an  excellent  training  tool  that  has  reduced  the  Overall  amount  of  train- 
ing required  and  has  improved  the  quality  of  training. 

IMPLEMENTING  CHANGES.  Nearly  every  facility  contacted  has  a list  of  proposed 
changes  they  would  like  to  see  made  to  the  simulation  software  to  ease  the 
simulator  pilot  burden  or  to  improve  realism.  A prime  complaint  was  the  length 
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of  time  necessary  to  implement  what  appeared  to  be  relatively  simple  changes. 

Some  of  the  most  significant  proposed  changes  appeared  in  subsequent  program 
modifications  that  were  not  yet  in  use  at  the  facilities  concerned.  The  priority 
level  for  DYSIM  or  ETG  changes  is  obviously  not  as  high  as  changes  to  improve 
or  correct  the  operational  program.  Most  training  staff  people  contacted  feel 
that  they  should  have  the  authority  to  independently  modify  their  training 
system  as  they  see  fit  to  meet  their  needs. 

Preparation  of  a new  enroute  training  problem  and  scenario  tape  is  an  exces- 
sively tedious,  time-consuming,  and  manpower-consuming  process.  Many  thousands 
of  new  cards  must  be  punched.  Airway  changes,  procedure  changes,  or  issuance  of 
a new  program  tape  require  that  cards  be  repunched.  At  the  time  of  our  dis- 
cussions with  training  staffs,  reading  the  card  decks  into  the  central  computer 
often  caused  program  aborts.  Changing  from  card  to  tape  input  solved  this 
problem  but  required  even  more  card  punching.  (One  center  required  52,000 
cards  for  its  DYSIM  problems,  and  104,000  cards  to  convert  to  tape.) 

OPERATIONAL  IMPACT  OF  TRAINING.  A problem  area  that  may  just  be  emerging  is 
the  saturation  of  track  tables  while  DYSIM  and  ETG  are  running.  No  one  iden- 
tified any  impact  on  training  resulting  from  this  problem.  However,  it  was 
noted  that  some  centers  do  not  run  high  density  DYSIM  problems  during  peak 
traffic  periods  in  order  to  avoid  automatic  shutdown  of  DYSIM.  (Such  an 
occurrence  would  affect  DYSIM  only,  not  the  operational  program.  See  Software 
Analysis.)  Terminals  also  anticipate  having  eventually  to  schedule  their 
training  during  off-peak  hours  for  similar  reasons. 

SUMMARY.  Some  facilities  claim  to  have  few  of  the  problems  cited.  Such 
facilities  are  the  exception,  and,  as  far  as  is  known,  those  sites  with  a 
well  equipped  operational  facility,  a well-equipped  laboratory,  and  a large 
training  staff  substantially  supported  by  data  systems  specialists.  A more 
indepth  study  of  the  total  field  training  status,  utilization,  short-comings, 
and  results  will  be  contained  in  a subsequent  project  (216-103-120,  Enroute 
and  ARTS  III  Facility  Training  Enhancements)  planned  for  completion  in 
February  1978. 

SIMULATOR  PILOT  POSITIONS. 

SIMULATOR  PILOTS.  In  many  facilities,  the  simulator  pilot  is  a developmental 
controller  who  may  be  taking  instruction  in  radar,  himself.  Another  facility 
may  use  a Full  Performance  Level  (FPL)  controller  as  a pilot.  As  stated  ear- 
lier, the  EPDS  often  acts  as  both  pilot  and  instructor.  Some  facilities  use 
hired  target  generator  operators.  Generally,  however,  developmental  controllers 
serve  as  simulator  pilots  in  centers,  with  the  exception  that  they  do  not  serve 
as  simulator  pilots  for  FPL  or  supervisory  proficiency  testing.  Ordinarily, 
the  simulator  pilot  also  performs  ghost  functions  appropriate,  to  that  position 
(that  is,  the  functions  associated  with  facilities  or  positions  interfacing 
with  the  trainee).  Again,  a few  facilities  vary  this  procedure,  assigning 
other  personnel  (FPL,  developmental,  instructor)  to  perform  these  functions. 
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FUNCTIONS . Briefly  stated,  the  functions  performed  by  the  simulator  pilot  are: 


1.  Monitoring  the  air-ground  "frequency"  and  initiating  and  responding  to 
voice  communications. 

2.  Selecting  appropriate  entry  functions  and  making  associated  keyboard 
entries  to  offset  target  movement  (pilot  functions)  in  response  to  clearances 
and  instructions  received  from  the  controller  or  the  instructor,  called  for  by 
the  script,  or  required  by  procedures. 

3.  Making  operational  program  keyboard  entries,  usually  associated  with  ghost 
functions  such  as  handoff,  accept  handoff,  start  track,  and  drop  track. 

4.  Flight  strip  marking  (reminders  of  future  actions  to  be  taken  such  as 
holding,  altitude  changes,  etc.). 

5.  Offsetting  data  blocks  to  alleviate  display  clutter. 

6.  Checking  certain  data  entries  against  posted  look-up  tables  (conversion 
of  indicated  airspeed  to  true  airspeed,  climb/descent  rates,  etc.). 

The  simulator  pilot's  chief  problem  is  that  he  has  too  much  to  do  and  too  little 
time  in  which  to  do  it.  The  keyboard  entries  he  is  required  to  make  are  lengthy 
and  complex  and  often  several  entries  are  required  to  be  made  in  quick  succession. 
The  operators  of  the  pi.lot  position  and  the  training  staffs  interviewed  indi- 
cated that  there  is  a need  for  a pilot  entry  device  that  is  more  efficient  and 
easier  to  use. 

EQUIPMENT.  The  equipment  provided  at  the  pilot  positions  in  ARTS  III  and 
enroute  facilities  are  markedly  different.  In  a typical  terminal  facility, 
the  only  dedicated  pilot  equipment  may  be  one  portable'  ARTS  III  keyboard,  while 
in  a typical  enroute  facility,  each  pilot  occupies  the  equivalent  of  a center 
sector,  with  WD  and  associated  data  entry  devices  including  a Computer  Read- 
out Device  (CRD),  radar  controller's  alphanumeric  keyboard  with  trackball, 
Quick-Action  Keyboard  (QAK) , and  "D"  position  alphanumeric  keyboard.  The  alpha- 
numeric keyboards  in  use  in  terminals  and  centers  were  not  designed  for  use  as 
pilot  entry  devices  and  are  quite  dissimilar. 

PROCEDURES . The  procedure  for  making  pilot  data  entries  in  both  ETG  and  DYSIM 
are  similar;  the  flight  is  identified,  the  function  (heading,  speed,  altitude, 
or  beacon)  is  specified,  and  the  value  entered,  in  each  case  using  the  opera- 
tional alphanumeric  keyboard  to  make  the  entries.  Ghost  functions,  consisting 
primarily  of  making  and  accepting  handoff s and  starting  and  terminating  targets, 
are  executed  in  the  same  general  ways.  Both  systems  allow  the  use  of  scenario 
tapes  for  initial  entry  of  training  problems. 

DYSIM /ETG  CAPABILITIES.  With  minor  limitations,  all  normal  aircraft  motions  or 
responses  to  controller  clearances,  can  be  accommodated  by  both  simulation 
systems.  The  consistency  and  standardization  of  the  aircraft  motions  was,  how- 
ever, criticized  as  being  unrealistic  and  some  actions  required  considerable 
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ingenuity,  dexterity,  and  a good  memory  on  the  part  of  the  simulator  pilot. 

A scratch  pad  and  continuous  observation  of  the  position  of  the  aircraft  was 
required. 


When  used  for  training  purposes,  the  DYSIM  and  ETC  computer  programs  perform 
the  same  basic  functions,  which  are  that  of  generating  simulated  targets  and 
allowing  them  to  be  manipulated  by  means  of  commands  (simulating  pilot  response 
to  control  instructions)  that  control  heading,  speed,  altitude,  and  beacon 
response. 

DYSIM  has  some  target  control  capabilities  that  ETG  lacks.  Conversely,  ETG 
has  some  capabilities  that  DYSIM  lacks.  For  example,  holding  pattern  leg 
length  and  360°  turns  are  provided  for  in  DYSIM  but  not  in  ETG.  On  the  other 
hand,  ETG  has  the  capability  to  "freeze"  the  problem,  provides  specific  no-gyro 
turn  commands,  allows  direction  of  turn  to  be  specified,  and  has  its  own  wind 
factor,  none  of  which  DYSIM  has.  Other  differences  between  ETG  and  DYSIM  are 
the  result  of  inherent  differences  between  ARTS  III  and  the  enroute  system, 
such  as  the  fact  that  the  enroute  system  processes  primary  radar  returns  and 
stores  and  processes  flight  plan  data,  while  ARTS  III  does  neither. 

New  capabilities  and  refinements  are  gradually  being  added  to  DYSIM  and  ETG. 
Appendix  D compares  specific  ETG  and  DYSIM  data  entry  functions  that  were 
current  at  the  time  of  this  writing. 

PILOT  ENTRY  LIMITATIONS.  The  most  time  consuming  or  difficult  simulator  pilot 
input  in  the  enroute  facilities  was  the  target  initiation  process.  This  process 
included  a Start  Sim  message,  a Start  Track  message,  a Beacon  Mode  C message 
and  a Handoff  message.  These  messages  were  necessary  for  every  target  enter- 
ing the  training  problem.  This  problem  was  alleviated  in  a subsequent  program 
modification  (A3D2.3).  Automatic  track  initiation  was  provided  when  a Start 
Sim  message  was  entered  and  Beacon  Mode  C was  assumed  initially  on  all  flights 
since  this  condition  was  most  prevalent.  This  modification  reduced  the  target 
initiation  process  from  four  messages  to  two  messages. 

The  following  enroute  command  instructions  required  improvisation  and  extraneous 
entries  for  pilot  conformance. 

1.  When  e.  new  beacon  code  was  entered,  mode  C capability  had  to  be  included 
or  it  was  dropped.  This  was  changed  by  A3D2.3. 

2.  Direction  of  turn  cannot  be  specified  in  DYSIM.  The  target  will  turn  in 
the  direction  that  requires  the  least  change  in  heading.  No-gyro  turns  (turns 
in  a specified  direction  but  unspecified  amount)  were  accomplished  by  deter- 
mining the  present  heading  and  then  inputting  a heading  change  of  less  than 
180°  consistent  with  the  direction  of  command  turn.  Constant  surveillance 
was  required  by  the  pilot  so  that  if  a "stop  turn"  command  was  not  received 
from  the  controller  before  the  target  reached  the  input  heading,  a new  heading 
was  entered  to  keep  the  target  in  a turn.  The  pilot  response  to  a "stop  turn" 
command  was  to  check  the  target's  present  heading  and  enter  that  value  as  the 
new  command  heading. 
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3.  As  direction  of  turn  cannot  be  specified  for  a heading  change,  the  pilot 
response  to  a turn  of  more  than  180°  in  a specified  direction  was  to  enter  two 
separate  heading  messages.  The  first  heading  message  would  perhaps  change  the 
target's  present  heading  by  170°  and  the  second  message  would  be  the  command 
value  issued  in  the  clearance. 

4.  The  pilot  response  to  a command  to  climb  or  descend  to  an  altitude  at 
maximum  rate  or  to  expedite  climb  or  descent  was  to  determine  the  type  of  air- 
craft for  that  particular  target,  refer  to  a listing  of  aircraft  types  with 
associated  climb/descent  rates,  determine  the  type  of  aircraft  that  had  a 
higher  rate  than  the  type  previously  determined,  move  to  a non-radar  control 
(D)  position  and  enter  a Flight  Plan  Amendment  message  to  change  the  type  of 
aircraft  to  one  of  higher  performance.  When  this  was  accomplished  the  pilot 
would  move  back  to  the  simulator  pilot  position  to  input  the  command  altitude 
originally  issued.  Surveillance  of  that  targets  altitude  was  now  necessary 

so  that  when  the  command  altitude  was  reached  the  pilot  would  move  back  to 
the  D position  to  change  the  type  of  aircraft  back  to  the  original  type  so  that 
subsequent  altitude  changes  would  be  at  the  normal  rate. 

5.  Speed  change  commands  are  issued  in  indicated  airspeed,  and  the  pilot 
input  response  is  in  true  airspeed.  A conversion  listing  is  used  which  pro- 
vides average  true  airspeeds  based  on  an  average  altitude  with  respective 
indicated  airspeeds.  The  pilot  response  to  a change  of  speed  is  to  refer  to 
the  conversion  table  for  the  issued  indicated  speed,  find  the  comparative  true 
airspeed,  and  enter  that  value  in  the  speed  change  message.  If  a command  is 
received  to  "resume  normal  speed,"  the  pilot  determines  the  filed  true  air- 
speed from  the  flight  progress  strip  and  enters  that  value  in  the  speed  change 
message.  Speed  is  not  presently  displayed  in  enroute  data  blocks. 

6.  With  some  variations,  DYSIM  and  ETG  basically  operate  on  the  principle 
that  the  simulator  pilot,  rather  than  computer  logic, -is  the  initiator  of 
aircraft  motions.  That  is,  the  target  action  occurs  at  the  moment  of  simu- 
lator pilot  entry  and  specifically  as  directed  by  the  entry.  A clearance 

for  an  aircraft  to  proceed  from  present  position  direct  to  a fix,  for  instance, 
requires  that  the  simulator  pilot  observe  the  relative  positions  of  the  air- 
craft and  the  fix,  and  mentally  compute  and  enter  the  appropriate  specific 
heading  change  required.  Also,  any  clearance  requiring  compliance  at  a point 
or  time  in  the  future,  such  as  an  altitude  change  at  a fix  along  the  route  of 
flight,  requires  a notation  on  the  flight  progress  strip  and  surveillance  of 
the  aircraft  target.  When  the  aircraft  reaches  the  fix,  the  pilot  enters  the 
appropriate  command  and  the  command  action  is  initiated. 

In  terminal  facilities  a number  of  complex  codes  must  be  memorized  or  looked 
up  for  the  entry  of  appropriate  turn  rates,  speed  change  rates,  altitude  change 
rates,  beacon  code  validations,  etc. 

The  complexity  of  the  messages,  the  notations  and  referrals  for  messages  con- 
taining future  action,  the  lookup  tables  necessary  to  perform  some  actions, 
and  the  display  scanning  to  enter  a message  at  the  correct  time,  require  very 
close  attention  and  limit  the  number  of  aircraft  one  pilot  can  handle.  Four 


or  five  aircraft  simultaneously,  and  nine  or  ten  per  hour,  seem  to  be  the 
average  handled  by  proficient  pilots. 

ENTRY  ERRORS . Despite  the  above  problems,  the  operators  of  the  present  pilot 
position  devices  become  quite  proficient  in  a relatively  short  time  and  can 
be  trained  in  making  almost  error-free  entries.  Although  few  erroneous  entries 
were  observed,  the  potential  was  certainly  present  and  once  an  error  is  made 
it  is  difficult  to  recover  since  new  messages  are  being  received  while 
attempting  to  correct  the  error.  Some  of  the  messages  are  lost  and  can  affect 
the  developmental  controllers  performance  in  a pass/fail  training  situation. 

TRAINING  BENEFITS  TO  PILOT.  Some  training  benefit  is  gained  by  the  pilot  con- 
sole operator  in  using  the  operational  keyboard  and  scanning  the  graphic  dis- 
play of  the  traffic  situation.  This  benefit,  however,  is  minimal  since  the 
pilot  is  usually  too  busy  performing  his  function.  The  consensus  of  opinion 
was  that  a more  efficient  pilot  entry  device  to  help  the  pilot,  and  therefore 
the  controller  taking  the  problem,  is  more  important  than  the  familiarity  lost 
by  not  using  the  operational  devices.  The  pilot  operator  should  be  considered 
a support  position  rather  than  a training  position. 

DEVICE  ANALYSIS 


APPROACH. 

Experts  in  the  area  of  entry  devices  and  displays  were  queried,  briefings  were 
received  from  many  vendors  in  the  field;  articles,  reports,  and  brochures  on 
various  computer  systems,  entry  devices,  and  displays  were  read  to  determine 
the  state-of-the-art  and  the  ability  of  off-the-shelf  devices  to  meet  the  needs 
for  a simulator  pilot  console. 

Alternative  message  entry  devices  and  methods  which  could  provide  simpler  and 
quicker  entry  capability  with  a minimum  of  special  training  were  investigated. 
Currently  available  keyboard  layouts  were  analyzed,  including  that  used  in  The 
National  Aviation  Facilities  Experimental  Center  (NAFEC)  Digital  Simulation 
Facility  (DSF).  Keyboards  and  systems  designed  for  United  States  Air  Force 
(USAF)  and  Canadian  radar  controller  training  were  also  considered.  Recognizing 
the  advantage  of  having  a keyboard  which  is  identical  with  that  proposed  for 
use  in  the  FAA  Academy's  Radar  Training  Facility  (RTF),  the  functional  simi- 
larities and  differences  between  that  system  and  the  desired  subsystem  were 
analyzed  to  determine  the  practicality  of  that  approach.  Entry  devices  other 
than  keyboards,  such  as  touch  sensitive  displays,  were  also  investigated. 


About  halfway  through  the  project,  as  requested  by  the  SRDS  program  manager, 
a dynamic  model  of  the  entry  concept  considered  most  desirable  was  prepared  and 
demonstrated  at  NAFEC  using  available  NAFEC  equipment  and  facilities.  The  lead 
time  required  to  prepare  the  model  and  for  the  interface  analysis  effort  did  not 
permit  an  indepth  analysis  of  all  entry  possibilities.  An  early  decision  on  the 
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moat  promising  entry  device  was  made  primarily  on  the  basis  of  briefings  by 
various  vendors,  advertised  capabilities,  and  experience  with  similar  devices 
and  methods. 


ENTRY  DEVICE  INVESTIGATION. 

REQUIREMENTS . The  guidelines  required  that  we  simplify  the  simulator  pilot 
inputs,  interface  the  new  entry  device  with  the  current  DYSIM  and  ETC  cap- 
ability (without  significant  modification) , and  also  provide  a device  common 
for  both  enroute  and  ARTS  III  facilities.  A device  which  was  quick  and  easy 
to  learn  and  which  would  allow  an  increase  in  pilot  capability  with  reduced 
input  errors  was  desired. 

COMPARISON  WITH  OTHER  SIMULATORS.  A cursory  examination  of  the  simulator  pilot 
entry  capabilities  in  use  in  the  DSF,  and  planned  for  the  RTF,  pointed  out  some 
basic  conceptual  differences  between  those  systems  and  the  DYSIM/ETG  systems. 

In  the  DSF/RTF  concept  the  simulator  pilot  is  primarily  a translator  between 
the  controller  (oral  communications)  and  the  computer  (digital  data).  That  is 
the  simulator  pilot  orally  communicates  the  reports  generated  by  the  computer 
(and  portrayed  on  the  display)  to  the  controller,  and  enters  the  clearances 
received  from  the  controller  into  the  computer.  Aircraft  target  status,  position 
and  actions  are  maintained  by  the  computer  and  the  human  is  merely  the  medium 
of  information  exchange.  In  the  DYSIM/ETG  systems,  however,  simulator  pilots 
must  maintain  cognizance  of  the  status  and  position  of  the  aircraft  targets 
and  determine  the  specific  aircraft  status  reports  required  by  the  controller, 
and  actions  necessary  to  carry  out  the  received  clearances.  Also,  in  the  DSF/ 

RTF  concept,  in  order  to  allow  entry  of  the  various  possible  clearances,  a 
specialized  and  complex  functional  keyboard  was  devised  which  operates  with  a 
software  system  designed  to  control  the  simulator  pilot  entries.  Acceptable 
message  components  (aircraft,  fixes,  etc.)  and  syntax  are  maintained  by  the 
software.  Six  to  eight  weeks  of  special  training  is  necessary  for  new  simulator 
pilots  to  become  proficient  in  operating  the  keyboard.  This,  of  course,  would 
be  less  for  persons  familiar  with  air  traffic  control.  Nevertheless,  proficiency 
in  using  such  a system  would  require  additional  special  training  and  experience 
not  compatible  with  the  guidelines  and  realities  of  the  field  training  system. 

Other  systems  did  use  keyboards  more  compatible  with  DYSIM/ETG  requirements, 
but  they  too  were  designed  to  operate  with  specific  target  generation  systems. 
Modifications  appeared  necessary  to  adapt  them  to  current  DYSIM/ETG  capabilities. 

TOUCH  SENSITIVE  DEVICE  ENTRY.  The  entry  method  chosen  as  most  likely  to  pro- 
vide a simpler,  easier  to  use  entry  capability,  common  to  both  ETG  and  DYSIM 
application,  was  a touch  sensitive  display  overlay.  A number  of  possible  touch 
entry  techniques  available  off-the-shelf  from  various  vendors  were  investigated. 
Some  use  light  pens  or  sonic  devices  touching  the  display  to  trigger  the  entry. 
Others  identify  any  touch  (with  a finger,  for  instance)  on  the  face  of  the  tube 
by  interrupted  light  beams,  pressure  sensing  devices,  deflection  of  overlay 
surfaces  against  each  other,  impedence  changes,  etc.  It  was  determined  that 
such  devices  are  in  use  successfully  in  a number  of  applications.  Experiments 
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by  MITRE  and  NAFEC  also  have  established  the  feasibility  and  utility  of  such 
devices.  For  our  use  it  was  decided  that  a system  allowing  finger  touch  should 
be  used  rather  than  one  requiring  an  intermediate  device  like  a light  pen. 


As  with  the  DSF/RTF  concept,  the  method  chosen  required  that  acceptable  entries 
and  syntax  be  maintained  by  the  software.  The  aircraft  under  the  direction  of 
a simulator  pilot  are  listed  by  the  computer  on  a display  along  with  basic  data 
about  the  aircraft  (speed,  heading,  altitude,  and  beacon  code),  and  a list  of 
possible  entries  (referred  to  as  a menu  list).  The  touch  sensitive  overlay 
allows  the  pilot  to  select  the  action  he  wishes  to  take,  or  the  reference  air- 
craft and  flight  condition  he  wishes  to  change,  by  merely  touching  the  appro- 
priate item  on  the  face  of  the  display.  The  touch  on  the  display  face  is  picked 
up  by  the  touch  system  overlaying  the  display,  and  is  transmitted  to  the  soft- 
ware as  an  x-y  location.  The  software  then  identifies  the  data  at  that  location, 
not  unlike  a track  ball  entry  in  the  operational  system.  The  software  then 
displays  a menu  of  the  next  acceptable  data  (message  field)  dependent  on  the 
entry  previously  identified.  Thus,  the  operator  can  proceed  in  proper  logical 
order  through  all  fields  of  any  possible  message.  Data  entry  errors  are  thus 
eliminated  and  virtually  no  training  is  required  as  the  software  controls  the 
entry  sequence  in  essentially  the  same  order  as  a clearance  would  normally  be 
received.  Software  control  also  allows  for  the  differences  in  terminal  and 
enroute  type  of  clearances  with  no  differences  in  the  device  used  or  in  train- 
ing method.  Translation  of  the  entered  message  into  the  appropriate  ETG  or 
DYSIM  message,  or  messages  (in  proper  format  and  sequence),  is  also  accomplished 
by  software,  thus  eliminating  memorizing  or  looking  up  special  codes  and  formats. 

TOUCH  ENTRY  CONCEPT  EVALUATION. 

DISPLAY.  Appendix  E describes  the  initial  basic  display  and  entry  procedure 
prepared  for  the  model  constructed  at  NAFEC  for  evaluation  of  the  touch  entry/ 
menu  list  concept.  This  was  only  for  the  concept  evaluation  and  not  intended 
to  represent  the  final  display  format  or  procedures  recommended. 

EQUIPMENT.  A PDP-11  driving  a GT-44  display  system  with  a 14  inch  cathode 
ray  tube  was  programmed  at  NAFEC  for  the  evaluation.  Instead  of  the  preferred 
finger  touch  system,  a light  pen,  available  on  the  GT-44,  had  to  be  used.  The 
display  was  mounted  in  a console  similar  to  that  envisioned  for  a simulator 
pilot. 

SUBJECTS.  Nine  controllers  from  the  field  with  current  experience  in  DYSIM  or 
ETG  worked  at  NAFEC  for  2 days  participating  in  the  evaluation  of  this  entry 
concept  and  also  adding  to  our  knowledge  of  current  training  capabilities. 

Four  of  the  controllers  were  from  enroute  facilities  and  five  from  terminals, 
from  six  different  regions,  representing  facilities  with  a variety  of  traffic 
densities.  All  of  them  were  familiar  with  simulation  training,  and  all  had 
served  as  simulator  pilots. 

METHODS.  The  concept  was  first  demonstrated  to  the  controllers  from  terminal 
facilities  and  then  hands-on  time  was  provided  for  each.  During  the  hands-on 
time,  air  traffic  control  clearances  were  issued  by  project  personnel.  The 
controllers,  acting  as  simulator  pilots,  made  appropriate  data  entries  in 


13 


response  to  the  clearances.  Debriefings  were  held,  and  questionnaires  were 
completed  by  the  controllers.  The  same  procedures  were  later  followed  with 
the  controllers  from  enroute  facilities. 

The  debriefings  permitted  a free  discussion  of  the  data  entry  and  display  con- 
cept being  evaluated  and,  incidentally,  provided  project  personnel  with  specific 
information  on  the  training  requirements  peculiar  to  different  facilities. 

RESULTS . The  personnel  involved  in  the  touch  entry  device  evaluation  at  NAFEC 
believed  the  concept  to  be  highly  beneficial  in  reducing  pilot  workload  and 
reducing  error  potential.  These  benefits  could  then  increase  the  aircraft 
handling  capacity  of  the  pilot  and  possibly  decrease  the  number  of  pilots 
necessary  to  support  a training  problem.  No  measures  are  available  to  define 
the  increased  capacity  but  best  guess  estimates  indicate  a possible  50  to 
100  percent  increase  in  the  present  capacity.  The  controller  responses  to 
the  questionaires  are  compiled  on  the  sample  questionaires  in  appendix  F. 

DISPLAY  INVESTIGATION. 

APPROACH.  Six  categories  of  display  systems  were  investigated  by  MITRE  for  use 
as  the  pilot  console  displays: 

1.  Random  Position  Graphics 

2.  PPI  Shared  Mode 

3.  High  Resolution  TV,  Bit  Image  Memory 

4.  High  Resolution  TV,  Scan  Converter  Memory 

5.  Plasma  Panel 

6.  Direct  View  Storage  Tube 

Table  1 summarizes  the  comparison  of  these  display  systems. 

The  intent  of  this  investigation  was  to  consider  the  applicability  of  a 
category  of  display  for  the  pilot  console  function,  and  not  to  recommend  a 
particular  manufacturer's  display,  although  an  example  of  a display  is  shown 
in  each  case.  Two  different  kinds  of  data  presentation  are  involved  at  the 
pilot  position.  One  is  alphanumeric  data  in  tabular  form  (tabular  display), 
such  as  lists  of  information;  the  other  is  data  in  graphic  form  (graphic- 
display),  such  as  a radar  display  with  moving  targets,  data  blocks,  maps,  and 
symbols. 

RESULTS.  The  results  of  this  investigation  showed  that  relatively  inexpensive 
display  systems,  capable  of  meeting  the  needs  of  a simulator  pilot  position, 
are  available.  The  type  of  system  most  likely  to  meet  the  graphic  display 
needs  at  a reasonable  cost  (about  $10,000)  was  the  high  resolution,  TV-type 
system  with  scan  converter  memory.  If  only  a tabular  display  is  required, 
lesser  quality  is  acceptable  and  such  displays,  adequate  to  the  needs,  can  be 
obtained  for  about  $3,000. 
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TABULAR  VERSUS  GRAPHIC  REQUIREMENTS. 

The  determination  to  use  a tabular  touch  sensitive  display  for  message  entry 
and  the  relative  display  cost  differences  posed  a question  of  the  necessity 
for  having  a graphic  display  for  the  simulator  pilot.  As  described  earlier, 
the  DYSIM/ETG  concept  assumes  that  the  human  simulator  pilot,  rather  than  the 
computer,  is  maintaining  cognizance  of  each  aircraft's  status  and  position. 
Therefore,  a graphic  display  appeared  essential.  Specifically  such  a display 
provides : 

1.  Flexibility  of  starting  a target  anywhere  on  the  display  by  identifying 
x-y  coordinates  with  a trackball  or  touch  overlay. 

2.  A reference  for  determining  target  position  for  handoff  and  terminate 
functions. 

3.  A reference  for  target  position  to  input  actions  at  future  points. 

4.  Some  training  value  by  allowing  a trainee  acting  as  simulator  pilot  to 
visualize  the  situation. 

The  introduction  of  an  interface  processor,  which  would  display  graphically 
the  map  and  target  data  received  from  the  main  enroute  or  ARTS  III  computer, 
however,  introduced  the  possibility  that  it,  rather  than  the  human,  could  main- 
tain aircraft  target  status  and  positional  relationship  to  the  map.  Operational 
advantages  of  such  a capability  were  readily  apparent.  No  longer  would  the 
simulator  pilot  have  to  use  memory  joggers  or  mental  calculations  to  carry  out 
required  aircraft  actions.  Clearances  could  be  entered  immediately,  as  received, 
and  the  computer  would  determine  the  appropriate  heading  to  a fix,  and  the  time 
to  send  the  appropriate  message  to  DYSIM  or  ETG  based  on  its  maintenance  of  the 
target/map  association.  The  pilot's  target-handling  capability  would  most  cer- 
tainly be  increased,  and  errors,  delayed  actions,  etc.,  would  be  decreased. 
Programming,  of  course,  would  be  significantly  increased,  but  this  would  be  a 
one-time  cost. 

If  the  cheaper  tabular  displays  could  be  used,  instead  of  the  graphic  displays, 
the  program  costs  might  be  offset.  However,  another  use  of  the  graphic  displays 
was  uncovered  during  our  investigation  which  makes  their  elimination  infeasible 
at  present.  The  instructors,  in  some  facilities,  use  the  graphic  displays  at 
simulator  pilot  positions  to  visualize,  modify,  or  create  desired  problem 
situations.  Such  a capability  is  essential,  especially  during  high-density 
training  and  testing.  At  some  facilities  simulated  targets  are  affected  by  the 
winds  aloft,  resident  in  the  operational  system.  This  could  prevent  preplanned 
traffic  situations  from  developing,  unless  the  problem  is  modified  by  instructor 
intervention.  Also,  instructors  attempt  to  dynamically  modify  a training  sit- 
uation to  best  exercise  a trainee’s  weak  areas.  Some  instructors  feel  that 
such  actions  are  virtually  impossible  to  accomplish  looking  over  the  shoulder 
at  the  controller  trainee's  scope  and  must  be  performed  at  the  simulator  pilot 
position. 
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If  graphic  display  presentation  is  required,  then  the  touch  sensitive  entry 
requirement  means  that  both  graphic  and  tabular  presentations  are  necessary. 
This  could  be  accomplished  by:  1.  using  a single  display  switchable  between 
graphic  and  tabular  presentation,  2.  providing  a single  display  containing 
both  tabular  and  graphic  data  simultaneously  at  each  simulator  pilot  position, 
or  3.  providing  separate  graphic  and  tabular  displays. 

The  first  option  appears  to  be  unacceptable,  as  the  need  for  information  from 
both  sources  is  frequently  simultaneous.  This  opinion  was  supported  by  a 
limited  survey  of  ATCS's,  EPDS's,  and  EPDO's. 

The  second  option  poses  a problem  of  display  size.  Dedicated  areas  for  graphic 
and  tabular  data  would  be  required  which  did  not  infringe  upon  each  other,  and 
the  graphic  area  must  be  large  enough  to  clearly  depict  the  same  data  as  is 
presently  on  the  PVD's  and  DED's.  When  larger  scopes  are  used,  the  edge  areas 
(most  likely  the  areas  used  for  the  tabular  data)  would  probably  have  con- 
siderable parallax,  making  it  unacceptable  for  touch  entry.  Some  vendors, 
however,  claim  to  have  larger,  virtually  flat  face  displays  which  could  be 
used  as  described. 

The  last  option  would  satisfactorily  meet  the  needs,  but  obviously  at  an 
increased  cost.  This  could  be  reduced  if  the  graphic  displays  were  considered 
for  instructor  use  only,  in  which  case  one  additional  graphic  display  for  each 
controller  position  (half  the  number  of  simulator  pilot  positions)  would  be 
required. 


INTERFACE  ANALYSIS 


APPROACH. 

A full  report  on  the  interface  analysis  carried  out  by  MITRE  Corporation  in 
support  of  this  project  is  contained  in  their  report  MTR-7437  (reference  2). 

The  analysis  examined  the  technical  feasibility  of  alternative  hardware  inter- 
face approaches,  estimated  the  costs  of  each  approach,  and  determined  the  soft- 
ware implications  of  each  approach  on  the  existing  operational  programs.  The 
constraints  on  the  analysis  (appendix  C)  were:  no  modifications  to  existing 
operational  hardware  was  allowed,  only  minor  modifications  to  existing  opera- 
tional software  was  allowed,  the  same  basic  hardware  for  the  enroute  and  terminal 
approaches  must  be  used,  standard  off-the-shelf  hardware  interfaces  must  be  used 
as  much  as  possible,  and  the  present  operational  capability  of  pilot  consoles 
must  be  maintained,  i.e.,  graphics  display  with  full  message  input  capability 
(either  touch  or  keyboard).  Full  tabular  displays  could  be  considered  as  a 
potential  cost  saving/enhanced  capability  option. 

The  following  is  a summary  of  the  results  of  the  technical  feasibility  analysis 
of  various  interface  approaches.  Information  on  costs  and  software  impacts 
will  be  discussed  later  in  the  report. 
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ENROUTE  FACILITIES. 


Three  basic  enroute  interface  approaches  were  examined  as  follows: 

APPROACH  1.  Interface  the  simulator  pilot  console  with  the  Computer  Display 
Channel  (CDC)  or  the  Display  Channel  Complex  (DCC)  display  subsystem  using  the 
present  Radar  Keyboard  Multiplexers  (RKM's).  Figure  1 is  a block  diagram  of 
the  hardware  interfaces  for  this  approach. 

Advantages  of  this  approach  are:  it  would  cause  no  change  to  the  CCC  to  CDC/ 

DCC  interface,  the  Display  Generator  (DG)/PVD  combination  would  be  released 
for  operational  use,  a high  quality  graphics  display  would  be  used,  and  it 
would  require  very  few,  if  any,  changes  to  CCC  or  CDC/DCC  software. 

Disadvantages  are:  This  interface  requires  the  use  of  relatively  large  and 
expensive  displays,  touch  entry  devices  are  not  feasible  on  this  size  display, 
additional  RKM's  and  Refresh  Memory  Input/Output  Control  (RMIOC)  ports  may  be 
required,  and  this  is  the  most  expensive  enroute  interface  approach. 

APPROACH  2.  Interface  the  simulator  pilot  console  with  the  CCC  via  either  the 
Input/Output  Control  Element  (IOCE)  Selector  Channels,  or  through  a Peripheral 
Adapter  Module  (PAM)  using  General  Purpose  Input  (GPI)  and  General  Purpose  Out- 
put (GPO)  adapters  to  interface  with  the  IOCE  Multiplexer  (MPX)  Channels. 

Figure  2 is  a block  diagram  of  the  hardware  interfaces  for  this  approach. 

From  a technical  standpoint,  this  approach  meets  all  of  the  basic  requirements 
such  as:  no  modifications  to  operational  hardware  are  required,  only  2 man- 
years  effort  is  required  for  the  software  interface  with  the  CCC,  the  same 
hardware  can  be  used  in  the  preferred  terminal  approach,  standard  off-the-shelf 
hardware  interfaces  are  used,  and  the  present  operational  capability  can  be 
maintained  (graphical  display). 

Other  advantages  are:  the  pilot  positions  will  be  able  to  function  as  ghost 
positions,  the  pilot  consoles  are  smaller  than  PVD's  or  ARTS  III  consoles,  the 
hardware/sof tware  development  will  not  be  difficult,  the  pilot  subsystem  can 
easily  be  converted  to  a full  stand-alone  system  when  desired,  and  the  inter- 
face hardware  will  be  compatible  with  any  replacement  subsystems  of  the 
enroute  or  terminal  systems. 

The  negative,  or  questionable,  aspects  of  this  approach  are:  CCC  software 
changes  are  required  to  send  only  target  and  full  data  block  information  on 
training  target  flights  to  the  interface  processor,  and  CCC  software  changes 
are  required  to  accept  simulator  pilot  inputs  from  a different  channel  than  the 
CDC/DCC. 

APPROACH  3.  Interface  the  simulator  pilot  console  with  the  CCC  via  the  PAM 
Common  Digitizer  (CD)  adapter.  Figure  3 is  a block  diagram  of  the  hardware 
interfaces  for  this  approach. 


18 


FIGURE  1.  ENRO'JTE  INTERFACE  APPROACH  1:  INTERFACE  THE  SIMULATOR 
PILOT  CONSOLES  WITH  THE  CDC  OR  DCC  DISPLAY  SUBSYSTEMS 
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FIGURE  2.  ENROUTE  INTERFACE  APPROACH  2:  INTERFACE  THE  SIMULATOR 
PILOT  CONSOLES  WITH  THE  CCC 
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FIGURE  3.  ENROUTE  INTERFACE  APPROACH  3:  INTERFACE  THE  SIMULATOR 
PILOT  CONSOLES  WITH  THE  CD  ADAPTER 
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The  positive  features  of  this  approach  are:  The  simulation  targets  would 
appear  as  normal  radar  targets  to  the  CCC,  and  a major  subprogram  DYSIM  could 
be  off-loaded. 

The  disadvantages  are:  This  interface  requires  all  of  the  equipment  required 
by  the  CCC  interface  approach,  and,  in  addition,  requires  the  CD  interface 
development  and  equipment  purchase;  the  software  development  is  more  difficult 
and  expensive  as  target  generation  must  be  performed  in  the  interface  processor; 
and  it  is  the  second  most  expensive  enroute  interface  approach. 

RESULTS . The  second  enroute  approach,  the  CCC  interface  through  the  PAM,  was 
determined  to  be  the  preferred  approach  from  both  a cost  and  technical  stand- 
point. 

TERMINAL  FACILITIES. 

Two  basic  terminal  ARTS  III  interface  approaches  were  examined: 

APPROACH  1.  Interface  the  simulator  pilot  console  with  the  Multiplexer  and 
Multiplexed  Display  Buffer  Memory  (MDBM)  in  the  ARTS  III-A  and  with  the  IOP 
in  ARTS  III.  Figure  4 is  a block  diagram  of  the  hardware  interfaces  for  this 
approach. 

The  positive  features  of  this  approach  are:  interfacing  at  the  MDBM  would 
cause  no  change  to  the  IOP-B  to  MDBM  interface,  and  software  changes  to  the 
existing  system  would  be  minimal,  requiring  only  normal  adaptation  changes  to 
the  IOP. 

The  negative,  or  questionable,  aspects  of  this  approach  are:  Each  MDBM  would 
service  up  to  four  simulator  pilot  consoles,  eight  consoles  at  a facility 
would  require  additional  MDBM's  at  each  site;  if  target  generation  at  the  pilot 
consoles  is  a possible  future  requirement,  this  interface  approach  should  not 
be  used  as  these  features  are  not  feasible  at  ATRS  III-A  installations  using 
this  approach. 

APPROACH  2.  Interface  the  simulator  pilot  console  with  the  IOP  in  ARTS  III 
and  with  the  IOP-B  in  ARTS  III-A.  Figure  5 is  a block  diagram  of  the  hardware 
interfaces  for  this  approach. 


The  positive  features  of  this  approach  are:  The  IOP  interface  is  not  a diffi- 
cult interface,  additional  MDBM's  would  not  be  required,  a very  high  quality 
display  is  not  required,  map  information  needed  at  the  simulator  pilot  consoles 
could  be  stored  in,  and  provided  by,  the  interface/display  processors,  touch 
input  can  be  fitted  to  this  category  of  display  due  to  the  small  size. 


Additional  advantages  of  this  approach  are:  Since  most  (or  all)  components  in 
this  system  are  commercially  available  off-the-shelf,  maintenance  problems  are 
reduced,  the  reliability  of  most  system  components  can  be  determined  prior  to 
purchase,  the  same  equipment  could  be  used  for  enroute  (using  enroute 
approach  2),  ARTS  III,  and  ARTS  III-A  facilities,  thereby  reducing  provisioning 
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FIGURE  4. 


ARTS  III 
77-36-4 

ARTS  INTERFACE  APPROACH  1:  INTERFACE  THE  SIMULATOR  PILOT  CONSOLE 
WITH  THE  MDBM  IN  ARTS  III -A  AND  WITH  THE  IOP  IN  ARTS  III 
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and  training  problems,  and  the  software  change  to  the  existing  system  would  be 
minimal,  requiring  only  normal  adaptation  changes  to  the  10P. 

In  addition,  if  target  generation  or  stand-alone  capability  is  desired  in  the 
future,  it  can  be  provided  by  changes  to  the  interface  processor  software.  If 
additional  interface  processor  hardware  is  needed,  a modular  hardware  design 
approach  would  make  this  feasible.  System  configuration  changes  (more  or 
fewer  pilot  consoles,  master  and  slave  units,  etc.)  are  easy  to  accomplish. 
Systems  could  be  implemented  on  a modular  basis.  If,  at  some  later  date,  a 
major  system  is  replaced  (enroute,  ARTS),  the  pilot  console  system  could  be 
retained  and  integrated  with  the  replacement  computer  system. 


MEMORY 


ARTS  III  OR  III-A 
77-36-5 

FIGURE  5.  ARTS  INTERFACE  APPROACH  2:  INTERFACE  THE  SIMULATOR 
PILOT  CONSOLES  WITH  THE  IOP  AND  IOP-B 


A negative,  or  questionable  aspect  of  this  approach  is'  that  the  size  of  the 
interface  processors  included  in  the  cost  estimate  for  this  approach,  will  not 
permit  software  development.  To  provide  this  capability  would  about  double  the 
cost  of  the  interface  processors  (mainly  to  purchase  peripheral  equipment). 


RESULTS.  The  preferred  approach  from  both  a cost  and  technical  standpoint 
appears  to  be  approach  2,  IOP  Interface. 

OTHER  INTERFACE  ALTERNATIVES. 

In  addition  to  the  approaches  discussed  above,  several  other  alternative 
approaches  using  redundant  or  existing  operational  equipment  were  examined, 

i.e.,  the  use  of  the  redundant  CDC  or  DCC  at  the  enroute  centers,  the  use  of 
the  redundant  IOCE's  at  the  enroute  centers,  the  use  of  ARTS  II  consoles,  the 
use  of  redundant  IOP's  in  the  terminal  facilities,  and  the  use  of  redundant 
Direct  Access  Radar  Channel  (DARC)  equipment  at  the  enroute  centers. 

The  most  promising  of  the  alternatives  is  the  latter  one,  the  use  of  DARC  equip- 
ment, which  could  reduce  the  cost  of  the  preferred  enroute  approach.  It  would 
have  no  effect  on  the  terminal  approaches  except  to  establish  which  interface 
processor  would  be  used  if  the  same  hardware  were  bought  for  both  the  enroute 
and  terminal  systems. 


SOFTWARE  ANALYSIS 


APPROACH. 

An  analysis  of  the  software  impact  on  the  existing  field  automation  systems 
resulting  from  interfacing  the  new  consoles  and  increasing  the  training  load 
was  provided  by  the  SRDS  Development  Programming  Branch  (ARD-140)  at  NAFEC, 
and  by  MITRE.  Advice  and  consultation  was  also  received  from  the  National 
Enroute  Data  Systems  Branch  (AAT-540)  and  National  Terminal  Data  Systems 
Branch  (AAT-550)  also  at  NAFEC. 

The  software  impact  of  the  new  simulator  pilot  consoles,  as  proposed,  had 
several  aspects  requiring  investigation: 

1.  The  magnitude  of  changes  to  the  operational  software  to  interface  a new 
processor  through  different  channels  as  proposed  by  MITRE. 

2.  The  magnitude  of  the  software  required  in  the  new  processor  to  perform 
the  desired  actions. 

3.  The  additional  software  impact  of  doing  target  to  map  association  in  the 
new  processor. 

4.  The  impact  on  available  computer  time  of  the  implied  increase  in  train- 
ing capability. 

5.  The  impact  of  future  proposed  changes  on  the  software  under  development 
to  accommodate  the  desired  system. 

Estimates  of  the  magnitude  of  operational  program  changes  were  obtained  from 
AAT-540  and  AAT-550  input.  Software  development  estimates  (number  of  instruc- 
tions) were  based  on  experience  from  the  DSF  at  NAFEC,  and  on  MITRE  experience 
in  the  development  of  the  Display  Demonstration  Capability  at  MITRE  METREK. 
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Despite  the  limitations  on  changes  to  the  existing  operational  and  simulation 
programs  laid  down  by  the  guidelines,  it  was  recognized  at  the  outset  that  any 
new  device  interfaced  through  a new  channel  to  the  operating  system  will  incur 
some  changes.  The  following,  for  the  most  part,  is  a summary  of  the  more  com- 
plete analysis  of  this  software  impact  contained  in  MITRE  report  MTR-7437 
(reference  2). 

BASIC  ENROUTE  SOFTWARE  IMPACT. 

APPROACH  1.  The  first  of  the  three  candidate  approaches  for  the  enroute  inter- 
face investigated  by  MITRE  (interface  pilot  console  with  CDC/DCC)  imposed  the 
least  impact  on  operational  system  software.  The  changes  required  were  pri- 
marily adaptation  changes  of  the  type  experienced  whenever  any  new  display  is 
added  to  the  system.  A processor,  required  to  replace  the  present  DG,  however, 
would  require  new  software  (about  8,000  instructions)  primarily  to  accept  the 
high  data  rate  from  the  CDC/DCC,  and  to  provide  appropriate  data  to  the  pilot 
display  at  a lower  rate. 

APPROACH  2 . The  preferred  second  enroute  interface  approach  (interface  of  the 
simulator  pilot  console  with  the  central  computer  via  the  PAM  using  GPI  and 
GPO  adapters)  would  require  changes  to  the  existing  monitor  programs.  A new 
program  code  would  also  be  required  to:  accept  inputs  from  a new  channel,  output 
appropriate  data  on  the  new  channel,  and  provide  the  logic  to  route  the  appro- 
priate data  to  one  of  the  two  channels,  in  addition  to  the  usual  adaptation 
changes  necessary  for  the  addition  of  any  new  display  to  the  system.  These 
changes  to  the  operating  system  are  estimated  at  about  2,500  lines  of  code. 

Under  this  approach,  new  software  must  be  developed  for  both  the  interface 
and  the  display  processors  to  perform  functions  for  the  pilot  displays  similar 
to  that  now  performed  by  the  CDC/DCC  for  both  the  trainee  and  pilot  displays. 
Those  CDC/DCC-like  functions  for  the  interface  processor  would  be: 

1.  Storage  and  presentation  of  the  map  with  fixes,  as  on  the  PVD,  without 
boundaries  or  other  controller  information. 

2.  Routing  of  data  by  display  address. 

3.  Handshake  with  the  CCC  and  data  rate  compatibility. 

Capability  to  perform  software  maintenance  should  also  be  included  as  a necessary 
function. 

The  CDC/DCC-like  functions  that  would  be  performed  by  the  display  processor  are: 

1.  Provide  storage  and  display  of  trail  history,  pilot  selectable  (may  not 
be  necessary  if  hardware  is  prohibitive,  and  the  heading  vector  or  the  heading 
alphanumerics  are  present). 

2.  Range  scale  and  offset  computations. 

3.  Trackball  processing. 
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Coordinate  conversion. 


5.  Keyboard  interpretation  and  input  message  processing. 

6.  Refresh  displays. 

The  following  additional  software  changes,  not  discussed  in  the  MITRE  report, 
should  also  be  made  to  the  enroute  DYSIM  program  in  order  to  most  efficiently 
utilize  the  capabilities  of  the.  proposed  new  simulator  pilot  consoles: 

1.  The  simulator  pilot  in  the  enroute  system  should  constantly  know  what  the 
speed  of  each  target  is  without  looking  it  up  in  the  flight  data  on  the  strips. 
Presently,  however,  speed  data  is  not  output  to  the  simulator  pilot.  A change 
should  be  made  to  DYSIM  to  output  this  information. 

2.  As  mentioned  in  the  Functional  Analysis  Section,  there  is  no  capability 
presently  in  DYSIM  to  change  the  rate  of  ascent  or  descent  of  a given  target 
without  changing  the  type  of  aircraft  with  a flight  plan  amendment  message,  and 
then  restoring  the  original  aircraft  type  with  another  amendment,  after  the 
ascent  or  descent  is  complete.  It  is  possible,  but  cumbersome,  to  have  the 
interface  processor  generate  these  same  false  messages  to  DYSIM  when  an  appro- 
priate change  of  rate  is  entered  by  the  simulator  pilot.  However,  DYSIM 
should  be  modified  to  permit  this  capability  without  such  gimmicks. 

3.  Similarly,  direction  of  turn  and  turn  without  a new  heading  (No-Gyro  turn) 
cannot  now  be  specified  in  DYSIM  by  the  simulator  pilot,  as  required  occasion- 
ally, without  multiple  messages  appropriately  timed.  Again  the  interface 
processor  could  be  programmed  to  enter  the  several  fake  messages  at  the  appro- 
priate time,  but  this  is  extremely  inefficient.  DYSIM  should  be  modified  to 
permit  a turn  in  a specified  direction  with  or  without  a new  heading,  and  to 
process  a stop  turn  message. 

The  magnitude  of  effort  to  accomplish  these  DYSIM  changes  was  not  determined. 

APPROACH  3.  The  third  enroute  interface  approach  investigated  (interface  the 
simulator  pilot  consoles  with  the  CD  adapter)  would  generate  targets  outside 
the  central  computer,  thus  eliminating  the  primary  function  of  DYSIM.  Major 
changes  would  be  required  to  accomplish  this  and  to  develop  another  software 
interface  to  provide  flight  data  to  the  new  Interface  processor.  The  software 
required  for  the  interface  processor  using  this  approach,  would  be  on  the  order 
of  creating  a new  DYSIM  (about  14,000  instructions).  In  addition,  a software 
interface  with  the  central  computer  to  gain  access  to  flight  record  files  and 
storage  for  these  data  would  be  required. 

BASIC  ARTS  SOFTWARE  IMPACT. 

The  two  candidate  approaches  for  ARTS  III  interface  investigated  by  MITRE  had 
identical  software  impact.  The  IOP  software  changes  would  be  essentially  the 
same  as  adding  any  new  displays  to  the  system.  The  new  interface  and  display 
processor  would  require  about  8,000  instructions  to  control  the  refresh  of  the 
display,  store  and  display  a map,  and  transfer  data  between  the  IOP  and  the 
display  and  between  the  display  Input  device  and  the  IOP. 
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TARGET/MAP  ASSOCIATION. 


In  MITRE's  analysis  of  software,  an  assumption  was  made  that  with  graphic  dis- 
plays at  the  simulator  pilot  positions,  the  simulator  pilot  entries  would  be 
limited  to  the  same  basic  entries  as  are  permitted  today  into  DYSIM  and  ETG, 
but  using  a greatly  simplified  method  (touch  panel  with  the  menu  list  as 
described  earlier).  That  is,  target/map  association  by  the  computer  (also 
described  earlier)  would  not  be  required.  The  above  software  estimates  were 
the  result  of  that  assumption.  They  did,  however,  also  estimate  the  software 
impact  (new  interface  software  development)  required,  if  only  tabular  displays 
were  available.  In  that  case,  the  simulator  pilot  would  not  be  able  to  visua- 
lize the  relationship  between  the  aircraft  target  position  and  map  points,  in 
order  to  respond  to  commands  such  as:  "maintain  altitude  to  a fix  point  and 
then  climb  to  another  altitude."  Later,  as  indicated  in  Device  Analysis,  it 
was  determined  that  target/map  association  in  the  interface  processor  was 
essential  to  obtaining  the  desired  improvements  to  the  simulator  pilot  cap- 
ability, regardless  of  the  displays  used. 

An  estimate  of  the  magnitude  of  performing  the  target/map  association  function 
in  the  interface  processor  was  made  based  on  the  number  of  instructions 
(26,000)  required  for  the  pilot  console  processing  in  the  DSF  at  NAFEC.  The 
DSF  target  generation  and  controller  console  processing  programs  are  not 
included  in  that  figure. 

Adding  the  target/map  association  function  to  the  interface  processor  for  the 
enroute  facilities  does  not  appear  to  impact  significantly  the  size  of  the 
processor  required.  In  the  enroute  facilities,  the  processor  must  be  adequate 
to  handle  up  to  16  simulator  pilot  consoles.  This  would  require  a processor 
which  could  also  adequately  handle  the  increased  processing  of  target /map 
association.  This,  however,  is  not  true  of  the  smaller  interface  processor  for 
terminal  sites  which  is  required  to  service  only  a makimum  of  eight  simulator 
pilot  consoles  and  normally  only  four.  Adding  the  target/map  association 
function  to  those  systems  will  require  a larger  interface  processor. 

INCREASED  TRAINING  CAPABILITY. 

REQUIREMENTS.  The  functional  requirements  in  the  guidelines  (appendix  C)  imply 
the  need  for  a significantly  increased  field  training  capability.  For  instance, 
whereas  the  largest  enroute  training  facility  in  the  field  today  has  four  stu- 
dent and  four  simulator  pilot  consoles,  the  functional  requirements  call  for 
a maximum  number  of  eight  student  consoles  and  16  pilot  consoles  per  facility. 

A similar  magnitude  of  increase  is  indicated  for  ARTS  III  facilities.  The 
maximum  number  of  targets  per  student  console  listed  in  the  functional  require- 
ments is  25  for  enroute  facilities  and  16  for  ARTS  III  facilities. 

ENROUTE  IMPACT.  Some  of  these  requirements  are  out  of’  line  with  the  capacities 
of  NAS  enroute  systems  and  DYSIM.  Some  of  them  exceed  the  needs  expressed  by 
field  training  people.  Presently,  the  enroute  systems  can  handle  a maximum 
total  of  60  simulated  targets  in  the  automatic  mode.  (In  automatic  mode,  the 
simulated  aircraft  is  associated  with  a flight  plan  and  will  automatically 
proceed  according  to  that  plan  unless  removed  by  pilot  action.  Manual  mode 
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requires  that  the  simulated  aircraft  movements  be  controlled  by  the  pilot. 

In  that  mode,  up  to  200  targets  are  acceptable.)  It  was  ascertained  that  the 
automatic  mode  limit  was  not  just  a function  of  the  assigned  table  space. 
Rather,  the  limit  of  60  is  imposed  by  the  fact  that  the  time  to  process  more 
than  60  simulated  targets  can  exceed  the  available  cycle  time.  Time-out  aborts 
could  occur  if  more  than  that  number  of  simulated  targets  required  processing. 
The  National  Enroute  Data  Systems  Branch  determined  that  the  present  method  of 
processing  automatic  mode  simulated  targets  could  be  considerably  improved  in 
order  to  reduce  the  processing  time.  They  estimate  that  about  9 man-months 
would  be  required  to  make  this  software  improvement.  The  magnitude  of  the 
resulting  increase  in  processing  simulated  targets,  however,  is  not  known. 

An  associated  problem  is  that  the  enroute  operational  program  possesses  a 
safety  feature  that  does  not  permit  DYSIM  to  function  when  the  track  tables 
become  filled  to  82.5  percent  of  capability.  This  82.5  percent  figure  includes 
tracks  input  from  DYSIM.  As  a result,  training  staffs  at  some  busier  facili- 
ties presently  avoid  running  100  percent  training  traffic  samples  during  peak 
"real  world"  traffic  handling  periods. 

Regarding  the  doubling  of  the  number  of  training  consoles  (from  four  to  eight 
maximum  in  ARTCC's)  and  adding  two  pilot  positions  for  each  training  console, 
it  soon  became  apparent  that  such  an  increase  would  much  more  than  double  the 
present  training  capability  of  any  center.  In  the  present  best  equipped 
laboratories,  four  pilot  positions  and  four  training  positions  do  not  permit 
running  four  simultaneous  training  problems  unless  all  four  problems  are  very 
elementary.  For  example,  if  two  50  percent  peak  load  traffic  samples  were 
run  in  this  laboratory,  only  two  controllers  could  be  trained,  because  each 
controller  requires  two  pilots.  This  leaves  two  training  positions  unutilized 
during  the  training  run,  which  is  not  an  uncommon  situation.  If  eight  training 
positions  and  16  pilot  consoles  were  provided,  the  training  capacity  might 
well  be  quadrupled.  Personnel  from  training  staffs  at  the  New  York  and 
Cleveland  Centers  stated  that  the  maximum  number  of  consoles  required  in  the 
foreseeable  future  for  controller  trainee  positions  would  be  six.  (Cleveland 
would  provide  four  of  these  consoles  for  training  developmental  controllers 
and  two  for  training  full-performance-level  controllers).  We  feel  that  this 
same  maximum  requirement  would  apply  to  any  center. 

ARTS  III  IMPACT.  The  ARTS  III  target  generating  limit  has  recently  been 
increased  to  64.  When  track  saturation  occurs,  training  track  files  are  auto- 
matically pre-empted  for  operational  use  as  needed. 

MAINTAINING  SOFTWARE  COMPATIBILITY. 

The  software  development  mentioned  previously  will  probably  be  the  pacing  item 
in  a procurement  of  new  simulator  pilot  consoles.  The  decision  to  include 
target/map  association  actions  adds  to  the  technical  risk  fob  software  develop- 
ment and,  therefore,  the  time  for  obtaining  an  operational  system.  A rough 
estimate  of  the  time  to  develop  the  necessary  software  would  be  1 year  after 
the  start  of  the  contract.  The  requirement  for  a functional  specification  by 
April  1,  1977,  was  established  because  of  the  need  to  let  the  contract  prior 
to  the  end  of  fiscal  year  1978  (September  31,  1978).  (Lead  time  of  about 
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18  months  is  common  for  a contract  of  this  magnitude.)  Therefore,  it  can  be 
assumed  that  delivery  of  the  first  new  simulator  pilot  console  system,  ready 
for  use,  will  not  be  for  at  least  2 1/2  to  3 years.  This  time  lag  could  cause 
a problem  of  software  compatibility. 

As  noted  in  Functional  Analysis,  most  every  facility  actively  using  DYSIM  or 
ETG  has  proposed  changes  which  they  feel  will  improve  the  realism  or  reduce 
the  simulator  pilot  burden.  Over  the  next  2 1/2  years  many  more  such  change 
proposals  can  be  anticipated.  ATS  has  stated  that  they  intend  to  increase  the 
rate  of  implementation  of  such  proposals  in  order  to  provide  needed  improve- 
ments to  the  field  training  capabilities.  This,  of  course,  is  commendable 
and  must  be  permitted;  however,  according  to  the  received  guidelines  and  con- 
tract specification  requirements,  the  new  simulator  pilot  consoles  must  inter- 
face with  DYSIM  and  ETG,  essentially  as  they  are  anticipated  to  be  at  the  time 
the  contract  is  let.  An  attempt  was  made  to  include  changes  now  anticipated 
for  future  program  modifications  in  the  preparation  of  the  functional  specifi- 
cation. Other  changes  processed  during  the  development  of  the  new  system  will 
require  either  continuous  modification  of  the  contract  during  the  development, 
or  an  immediate  software  update  upon  completion  of  the  contract,  in  order  to 
assure  compatibility  with  DYSIM  and  ETG  as  they  exist  at  that  time.  It  is 
also  probable  that  some  changes,  made  to  DYSIM  and  ETG  in  the  interim,  will 
have  to  be  removed  as  they  will  duplicate  functions  in  the  new  interface  proc- 
essor. 


COST  ANALYSIS 


APPROACH. 

The  analysis  of  various  interface  possibilities  conduc-ted  by  MITRE  and  fully 
reported  in  MTR-7437  (reference  2)  included  an  estimate  of  the  costs  of  each 
of  the  three  enroute,  and  two  ARTS  III  interface  approaches  investigated  by 
them.  These  estimates  were  based  on  their  knowledge  of  the  current  components 
of  the  field  automation  systems,  off-the-shelf  costs  of  various  possible  com- 
ponents as  received  from  manufacturers,  and  experience  in  the  development  of 
other  systems.  Software  development  costs  were  estimated  at  the  rate  of 
$35  per  instruction,  based  on  experience  with  other  systems  and  the  assumption 
that  this  software  would  have  a relatively  low  level  of  documentation  and 
heavy  emphasis  on  assembly  language. 

When  preparing  the  basic  costs,  MITRE  made  an  initial  assumption  that  only 
graphic  displays  would  be  used  and,  with  graphic  displays,  extensive  target/ 
map  association  functions  in  the  interface  processor  would  not  be  required. 

In  addition,  MITRE  prepared  alternative  cost  estimates  for  the  preferred 
enroute  interface:  (1)  using  the  DARC  equipment  at  the  enroute  centers  as  the 
interface  processor,  and  (2)  using  only  the  cheaper  tabular  displays,  with 
target/map  association  programming  in  the  interface  processors. 

Originally,  it  was  estimated  by  ATS  that  there  would  be  a requirement  for 
228  consoles  at  23  enroute  sites  (including  NAFEC  and  two  EARTS  sites),  and 
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130  consoles  at  63  ARTS  III  sites.  Recognizing  that  EARTS  sites  could  not  use 
the  same  specifications  as  other  enroute  facilities  because  of  their  use  of 
ARTS  III  type  of  processors,  MITRE  reduced  the  number  of  enroute  sites  to  21, 
but  otherwise  used  the  above  figures  for  their  cost  estimates. 

Subsequent  decisions  and  information  received  required  the  preparation  of  new 
cost  estimates:  1.  AFS  determined  that  the  DARC  equipment  should  not  be  con- 
sidered for  use  as  the  simulator  pilot  console  processor  (appendix  G) , 2. 

Target/map  association  programs  in  the  new  processor  were  determined  to  be 
essential  regardless  of  the  type  of  display  used,  3.  There  is  a strong 
possibility  that  both  a tabular  and  a graphic  display  will  be  required  to 
adequately  perform  the  desired  functions  (see  Device  Analysis),  4.  The  number 
of  enroute  consoles  included  in  the  fiscal  year  1978  budget  was  later  estab- 
lished as  114,  while  the  number  for  the  fiscal  year  1979  ARTS  III  procurement 
was  left  open,  and  5.  We  were  asked  to  determine  the  number  of  consoles  and 
sites  possible  within  the  $3.7  million  fiscal  year  1978  budget  for  enroute 
facilities  and  the  $4.6  million  estimated  for  ARTS  III  sites  in  fiscal  year 
1979.  These  new  estimates  were  prepared  by  combining  the  basic  data  provided  by 
MITRE.  A very  conservative  approach  was  taken,  in  that  the  costs  of  both 
tabular  and  graphic  displays,  and  a summation  of  both  software  estimates 
(with  and  without  target/map  association)  were  used. 

In  all  cases,  the  estimates  only  reflected  initial  contract  purchase  costs 
and  did  not  attempt  to  reflect  total  life  cycle  costs  of  the  systems,  nor  do 
they  reflect  in-hc^se  costs,  such  as  those  costs  necessary  for:  changes  and 
adaptation  of  the  basic  ARTS  III  and  enroute  software,  training  of  in-house 
personnel,  site  preparation  or  new  construction,  continuing  maintenance  and 
adaptation  of  the  delivered  software,  etc. 

In  the  following  sections,  the  costs  are  broken  into  "recurring"  (those  costs 
which  vary  according  to  the  number  of  units  of  each  item  required)  and  "non- 
recurring" (those  fixed  costs  required  no  matter  how  many  units  are  purchased). 
Program  management  and  contingency  costs  were  each  computed  as  10  percent  of 
the  costs  of  all  other  contract  items;  while  provisioning,  factory  inspection, 
and  freight  costs  were  percentages  (10,  5,  and  3 1/2  percent  respectively)  of 
the  total  hardware  costs  (i.e.,  all  items  under  recurring  costs,  except 
installation  and  site  test). 

BASIC  COSTS  OF  ENROUTE  INTERFACE  APPROACHES. 

Tables  2,  3,  and  4 depict  MITRE's  cost  estimates  for  each  of  the  three  enroute 
interface  approaches  investigated.  Costs  were  estimated  for  228  simulator 
pilot  consoles  at  20  ARTCC's  and  NAFEC.  Only  graphic  display  costs  are  shown 
and  costs  of  target/map  association  software  in  the  interface  processor  are  not 
included. 

BASIC  COSTS  OF  ARTS  III  INTERFACE  ALTERNATIVES. 

Tables  5 and  6 depict  MITRE's  cost  estimates  for  130  simulator  pilot  consoles 
at  63  ARTS  III  facilities  for  each  of  the  two  ARTS  III  interface  approaches 
investigated.  Only  graphic  display  costs  are  shown,  and  costs  of  target/map 
association  software  in  the  interface  processor  are  not  included. 
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TABLE  2.  ESTIMATED  COSTS  OF  ENROUTE  INTERFACE  APPROACH  1: 

INTERFACE  RAYTHEON  PILOT  CONSOLE  WITH  THE  CDC/DCC 


Total  Recurring  Costs 


Nonrecurring  Costs 

1) 


2) 


Display  Station  Software  Development 
(8,000  instructions  @ $35/instruction) 
Hardware  Development 


3)  Hardware  Documentation 

4)  Software  Documentation 

5)  Program  Management  (10%  of  Contract  cost) 

6)  Contingency  (10%  of  Contract  cost) 

7)  Provisioning  (10%  of  Hardware  cost) 

8)  Factory  Inspection  (5%  of  Hardware  cost) 

9)  Freight  (3*5%  of  Hardware  cost) 

Total  Nonrecurring  Costs 
Total  Costs  (Recurring  and  Nonrecurring) 


Recurring  Costs 

Unit 

No. 

Enroute 

Item 

Cost 

Req  ' d 

Cost 

1)  Display  Station  (Proc- 
essors + Graphics 

Display) 

$30,000 

228 

$6,840,000 

2)  Cables 

3,600 

21 

75,600 

3)  Installation  & Site  Test 

500 

21 

10,500 

$6,926,100 


$ 280,000 

250,000 

70.000 

50.000 
757,600 

757.600 

692.600 
346,300 
242,400 

$3,446,500 

$10,372,600 


NOTE:  Estimate  does  not  include  the  cost  of  additional  RKM's 

or  RMIOC's  if  needed. 

Software  development  estimates  (number  of  instructions) 
are  based  on  MITRE  experience  in  development  of  the  dis- 


TABLE  3.  ESTIMATED  COSTS  OF  ENROUTE  INTERFACE  APPROACH  2: 
INTERFACE  PILOT  CONSOLES  WITH  THE  CCC 


Recurring  Costs 


Unit 

No. 

Enroute 

Item 

Cost 

Req 'd. 

Cost 

1)  Interface  Processor 

$50,000 

21 

$1,050,000 

2)  Display  Processor  & 

10,000 

228 

2,280,000 

Graphics  Display 

3)  GPI/GPO  Interface  Proc- 

3,400 

21 

71,400 

essor  Interface 

4)  PAM  GPI  Adapters 

1,200 

42 

50,400 

5)  PAM  GPO  Adapters 

1,158 

42 

48,600 

6)  Cable  Driver/Receiver 

400 

228 

91,200 

Assembly 

7)  Data  Entry  Device 

1,000 

228 

228,000 

8)  Cables 

2,700 

21 

56,700 

9)  Installation  & Site  Test 

500 

21 

10,500 

Total  Recurring  Costs 

$3,886,800 

Nonrecurring  Costs 


1)  Display  Station  Software  Development* 

(8,000  instructions  @ $35/lnstruction) 

2)  GPI/GPO/Interface  Processor  Interface  Development 

3)  Data  Entry  Device  Development 

4)  Hardware  Documentation 

5)  Software  Documentation 

6)  Program  Management  (10%  of  Contract  cost) 

7)  Contingency  (10%  of  Contract  cost) 

8)  Provisioning  (10%  of  Hardware  cost) 

9)  Factory  Inspection  (5%  of  Hardware  cost) 

10)  Freight  (3^%  of  Hardware  cost) 


$ 280,000 

80,000 

10,000 

50,000 

50,000 

435,700 

435.700 

388.700 
194,300 
136,000 


Total  Nonrecurring  Costs 


$2,060,400 


Total  Costs  (Recurring  and  Nonrecurring)  $5,947 , 200 


* Software  development  estimate  (number  of  instructions)  is 
based  on  MITRE  experience  in  development  of  the  display 
demonstration  capability  at  MITRE  METREK. 
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TABLE  4.  ESTIMATED  COST  OF  ENROUTE  INTERFACE  APPROACH  3: 

INTERFACE  PILOT  CONSOLES  WITH  THE  CD  ADAPTER  TO 
GENERATE  SIMULATED  TARGETS  EXTERNAL  TO  THE  CCC 


Recurring  Costs 

Unit 

No. 

Enroute 

Item 

Cost 

Req'd. 

Cost 

1)  Interface  Processor 

$50,000 

21 

$1,050,000 

2)  Display  Processor  & 

10,000 

228 

2,288,000 

Graphics  Display 

3)  GPI/GPO/Interface  Proc- 

3,400 

21 

71,400 

essor  Interface 

4)  PAM  GPI  Adapters 

1,200 

42 

50,400 

5)  PAM  GPO  Adapters 

1,158 

42 

48,636 

6)  PAM  CD  Adapters 

2,910 

42 

122,220 

7)  Cable  Driver/Receiver 

400 

228 

91,200 

Assembly 

8)  Data  Entry  Device 

1,000 

228 

228,000 

9)  Cables 

2,900 

21 

60,900 

10)  Installation  & Site  Test 

700 

21 

14,700 

Total  Recurring  Costs 

$4,017,400 

Nonrecurring  Costs 

1)  Display  Station  Software  Development* 

$ 490,000 

(14,000  instructions  @ $35/instruction) 

2)  GPI/GPO/Interface  Processor  Interface 

80,000 

Development 

3)  CD/Interface  Processor  Interface  Development 

40,000 

4)  Data  Entry  Device  Development 

10,000 

5)  Hardware  Documentation 

65,000 

6)  Software  Documentation 

50,000 

7)  Program  Management  (10%  of 

Contract  cos 

t) 

475,200 

8)  Contingency  (10%  of  Contract  cost) 

475,200 

9)  Provisioning  (10%  of  Hardware  cost) 

401,700 

10)  Factory  Inspection  (5%  of 

Hardware  cos 

t) 

200,900 

11)  Freight  (3^%  of  Hardware 

cost) 

140,600 

Total  Nonrecurring  Costs 

$2,428,800 

Total  Costs  (Recurring 

& Nonrecurring) 

$6,446,200 

* Software  development  estimate  (number  of  instructions)  based 
on  experience  from  Digital  Simulation  Facility  at  NAFEC  and 
the  display  demonstration  capability  at  MITRE  METREK. 


A 
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TABLE  5.  ESTIMATED  COSTS  OF  ARTS  INTERFACE  APPROACH  1: 

INTERFACE  PILOT  CONSOLES  WITH  THE  MDBM 

IN 

ARTS  III-A  AND  DIRECTLY  WITH  THE 

IOP  IN  BASIC 

ARTS  III 

Recurring  Costs 

Unit 

No. 

Item 

Cost 

Req ' d . 

ARTS  Cost 

1) 

Interface  Processor 

$10,000 

63 

$ 630,000 

2) 

MDBM 

75,000 

29 

2,191,095 

3) 

Display  Processor  & 

10,000 

130 

1,300,000 

Graphics  Display 

4) 

IOP/MDBM/Interface 

4,000 

63 

252,000 

Processor  Interface 

5) 

Cable  Driver/Receiver 

400 

130 

52,000 

Assembly 

6) 

Data  Entry  Device 

1,000 

130 

130,000 

7) 

Cables 

1,100 

63 

69,300 

8) 

Installation  & Site  Test 

500 

63 

31,500 

Total  Recurring  Costs 

$4,655,900 

Nonrecurring  Costs 

1) 

Display  Station  Software  Development* 

$ 280,000 

(8,000  instructions  @ $35/instruction) 

2) 

IOP/MDBM/Interface  Processor  Interface 

Develop . 

100,000 

3) 

Data  Entry  Device  Development  (covered 

under 

Enroute  costs) 

• 

4) 

Hardware  Documentation 

50,000 

5) 

Software  Documentation 

50,000 

6) 

Program  Management  (10%  of 

Contract  cost) 

513,600 

7) 

Contingency  (10%  of  Contract  cost) 

513,600 

8) 

Provisioning  (10%  of  Hardware  cost) 

465,600 

9) 

Factory  Inspection  (5%  of 

Hardware  cos 

t) 

232,800 

10)  Freight  (34%  of  Hardware 

cost) 

163,000 

Total  Nonrecurring  Costs 

$2,368,600 

Total  Costs  (Recurring 

; & Nonrecurring) 

$7,024,500 

* Software  development  estimate  (number  of  instructions)  is  based 
on  MITRE  experience  in  development  of  the  display  demonstration 
capability  at  MITRE. METREK. 
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TABLE  6.  ESTIMATED  COSTS  OF  ARTS  INTERFACE  APPROACH  2: 

INTERFACE  PILOT  CONSOLES  DIRECTLY  WITH  THE 
IOP  IN  BOTH  ARTS  III-A  AND  BASIC  ARTS  III 


Recurring  Costs 


Unit 

No. 

Item 

Cost 

Req'd. 

ARTS  Cost 

1)  Interface  Processor 

$10,000 

63 

$ 630,000 

2)  Display  Processor  & 

10,000 

130 

1, 300,000 

Graphics  Display 

3)  IOP/Interf ace  Proc . 

4,000 

63 

252,000 

Interface 

4)  Cable  Driver/Receiver 

400 

130 

52,000 

Assembly 

5)  Data  Entry  Device 

1,000 

130 

130,000 

6)  Cables 

l,  100 

63 

69,300 

7)  Installation  & Site  Test  500 

63 

31,500 

Total 

Recurring  Costs 

$2,464,800 

Nonrecurring  Costs 


1)  Display  Station  Software  Development* 

(8,000  instructions  @ $35/instruction) 
IOP/Interf ace  Processor  Interface  Development 

3)  Data  Entry  Device  Development  (covered  under 
Enroute  Costs) 

4)  Hardware  Documentation 
Software  Documentation 

Program  Management  (10%  of  Contract  cost) 


2) 


5) 

6) 

7)  Contingency  (10%  of  Contract  cost) 

8)  Provisioning  (10%  of  Hardware  cost) 

9)  Factory  Inspection  (5%  of  Hardware  cost) 

10)  Freight  (3  1/2%  of  Hardware  cost) 

Total  Nonrecurring  Costs 
Total  Costs  (Recurring  & Nonrecurring) 


$ 280,000 
100,000 

50,000 

50,000 

294,500 

294.500 

246.500 
123,200 

86,300 

$1,525,000 

$3,989,800 


* Software  development  estimate  (number  of  instructions)  is 
based  on  MifRE  experience  in  development  of  the  display 
demonstration  capability  at  MITRE  METREK. 
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COST  SAVINGS  USING  DARC  AND  TABULAR  DISPLAYS. 


Table  7 depicts  MITRE's  cost  comparisons  between  the  preferred  basic  enroute 
CCC  interface  approach  using  a new  interface  processor  and  graphic  displays, 
and  the  same  approach  using  the  DARC  processor  for  the  interface  and  tabular 
displays. 

The  major  cost  saving  for  the  full  tabular  display  option  is  the  difference 
between  the  display  station  costs.  A graphics  display  is  estimated  to  cost 
$10,000,  whereas  the  cost  of  an  adequate  tabular  display  is  estimated  to  be 
only  $3,000.  These  savings  are  somewhat  offset  by  the  difference  in  the 
estimated  cost  of  software  development;  i.e.,  $280,000  for  the  graphic  display 
approach,  without  target/map  association  software,  and  $910,000  for  the  tabular 
display  approach,  with  such  software. 

For  the  DARC  option,  the  major  cost  saving  is  the  $50,000  interface  processor 
and  peripheral  equipment  at  each  enroute  site  since  the  DARC  processor  would 
already  be  installed  at  each  enroute  site.  The  other  savings  result  from  the 
fact  that  the  DARC  processor  would  already  be  interfaced  with  the  CCC/GPO. 

The  total  net  savings  are  estimated  to  be  about  $1.4  million.  It  is  important 
to  point  out  that  this  total  savings  could  not  be  attained  on  either  of  the 
other  enroute  approaches  since  they  Involve  a different  interface  with  the 
system.  Additional  savings  would  also  accrue  in  reduced  maintenence,  training, 
and  spare  parts.  Using  the  DARC  option  would  have  no  effect  on  the  ARTS  inter- 
face approaches  except  to  establish  which  interface  processor  would  be  used  if 
the  same  hardware  were  bought  for  both  the  enroute  and  terminal  systems. 

ADJUSTED  FINAL  COST  ESTIMATES. 

ENROUTE . Table  8 uses  the  basic  cost  estimates  received  from  MITRE  to  depict 
the  preferred  enroute  interface,  adjusted  to  114  consoles  at  21  sites,  with  both 
graphic  and  tabular  displays,  and  with  software  development  costs  for  target/map 
association  software  (the  sum  of  MITRE  software  estimates  used  for  tabular  and 
graphic  displays).  Site  and  console  costs  are  separated  to  allow  easy  compu- 
tation of  costs  for  various  numbers  of  sites  and  consoles.  Table  10  compares 
some  possible  combinations  of  numbers  of  consoles  and  sites  which  could  be  pro- 
vided within  the  fiscal  year  1978  budget  of  $3.7  million.  It  also  shows  the 
total  costs  for  both  114  and  228  consoles  at  21  sites  and  average  cost  per 
console  in  each  case. 

ARTS  III.  Table  9 uses  the  basic  cost  estimates  from  MITRE  to  depict  the  pre- 
ferred ARTS  III  interface,  adjusted  ito  the  number  of  consoles  and  sites  possible 
within  the  $4.6  million  planned  for  fiscal  year  1979,  with  both  graphic  and 
tabular  displays  and  with  software  development  costs  for  Larget/map  association 
(the  sum  of  MITRE’s  software  estimates  used  to  support  systems  using  graphic 
displays  and  those  with  tabular  displays).  In  this  case,  as  determined  by 
MITRE,  the  processor  wirh  limited  peripherals  in  the  original  MITRE  estimates 
would  not  be  able  to  support  the  larger  requirements  of  target /map  association. 
Therefore,  the  processor  costs  are  Increased  by  $15,000  each,  in  order  to  pro- 
vide a larger  processor  with  adequate  power.  Site  and  console  costs  in 
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TABLE  8.  ENROUTE  SIM.  PILOT  CONSOLES  CCC  INTERFACE  - BOTH  GRAPHIC  AND 
TABULAR  DISPLAYS 


1 
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*Coat  per  site  excluding  consoles 


TABLE  9.  ARTS  III  & ARTS  III-A  SIM.  PILOT  CONSOLES  IOP  OR  IOP-B 
INTERFACE  - BOTH  GRAPHIC  AND  TABULAR  DISPLAYS 


r 


♦ Cost  per  site  excluding  consoles. 


r 


TABLE  10. 


COST  COMPARISON  OF  VARIOUS  COMBINATIONS  OF  SIMULATOR  PILOT  CONSOLES 
AND  ENROUTE  SITES 


of  Consoles 

at  No.  of  Sites  = 

Total  Cost 

Avg. /Console 

228 

21 

$7,984,616 

$35,020 

114 

21 

$5,711,051 

$50,096 

38 

15 

$3,686,337 

$97,008 

51 

12 

$3,691,116 

$72,374 

55 

11 

$3,686,061 

$67,019 

60 

10 

$3,700,950 

$61,682 

TABLE  11. 

COST  COMPARISON  OF  VARIOUS 
CONSOLES  AND  ARTS  III  SITES 

COMBINATIONS  OF 

SIMULATOR  PILOT 

No.  of  Consoles 

at 

No.  of 

Sites  = 

Total  Cost 

Avg. /Console 

130 

63 

$6,924,896 

$53,268 

83 

30 

$4,592,007 

$55,325 

89 

27 

$4,584,819 

$51,514 

94 

25 

$4,599,961 

$48,935 
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Table  9 are  separated  to  allow  easy  computation  of  costs  for  various  numbers 
of  sites  and  consoles.  Table  11  compares  combinations  of  consoles  and  sites 


which  could  be  purchased  for  the  amount  planned.  It  also  shows  the  total  cost 
if  130  consoles  were  purchased  for  63  sites  and  the  average  cost  per  console 
in  each  case. 

Of  special  interest,  in  the  case  of  ARTS  III  facilities,  is  the  fact  that  the 
DEDS  equipment  now  used  for  this  purpose  costs  approximately  $110,000  each; 
however,  each  DEDS  can  accommodate  up  to  three  entry  positions  (or,  in  this 
case,  three  simulator  pilots).  Average  cost  per  simulator  pilot,  therefore, 
would  be  approximately  $33,000. 

FUTURE  UTILIZATION  OF  PILOT  CONSOLES. 

It  is  anticipated  that  upgraded  third  generation  programs  will  introduce 
heavier  storage  and  processing  demands  on  the  enroute  and  ARTS  III  computer 
facilities.  Because  the  storage  and  processing  capabilities  of  the  CCC  and 
the  IOP  are,  practically  speaking,  finite,  eventually  a decision  may  have  to 
be  made  to  abandon  the  use  of  DYSIM  or  ETG  or  both,  in  favor  of  one  or  more 
of  the  upgraded  third  generation  functions.  Also,  anticipated  increases  in 
air  traffic  will  increasingly  inhibit  the  use  of  DYSIM  as  the  82.5  percent 
track  table  capacity,  described  in  Software  Analysis,  is  reached  more  routinely. 
The  point  being  made  is  that  if  this  occurs,  or  when  it  occurs,  and  simulation 
capability  that  is  independent  from  the  operational  facility  is  mandated,  the 
simulator  pilot  console  hardware  would  be  salvageable  for  use  in  such  an  inde- 
pendent system. 


FUNCTIONAL  SPECIFICATION 


When  sufficient  information  had  been  accumulated  and  analyzed  to  allow  a deci- 
sion to  be  made  on  the  feasibility  and  desirability  of  using  more  cost  effec- 
tive, special-purpose,  pilot-simulator-type  consoles  in  the  field,  an  oral 
report  was  made  to  the  steering  group  charged  with  making  the  final  decision. 

A decision  to  proceed  with  the  procurement  will  require  a functional  specifi- 
cation; but  the  logistics  of  such  a procurement  requires  a lead  time  of  approx- 
imately 18  months.  As  the  enroute  procurement  was  budgeted  for  the  fiscal  year 
ending  September  30,  1978,  the  specification  was  requested  by  April  1,  1977, 
one  month  after  the  oral  presentation  to  the  steering  group.  This  was  insuf- 
ficient time  for  preparation  of  such  a document;  therefore,  as  soon  as  the 
best  interface  was  decided  upon,  and  the  decision  was  made  on  the  use  of  a 
touch  sensitive  input  device,  the  specification  was  started.  As  agreed, 

NAFEC  and  MITRE  prepared  Part  1 - Scope,  Part  2 - Applicable  Documents,  and 
Part  3 - Requirements.  Airway  Facilities  Service  had  the  responsibili*  r 

Part  4 - Quality  Assurance  Provisions,  and  Part  5 - Preparation  for  Dej.  *y. 


Although  the  hardware  portion  of  the  specifications  could  be  written  to  make 
them  usable  for  either  the  enroute  or  the  ARTS  III  interface,  this  was  not 
possible  for  the  software  portion.  That  is,  there  are  some  differences  in  the 
message  repertoire  between  the  systems,  and  there  is  a total  difference  in  the 
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message  formats  required  to  and  from  the  central  computer.  The  effort,  there- 
fore, concentrated  on  the  preparation  of  the  specifications  for  the  enroute 
interface  while  maintaining  knowledge  of  the  future  ARTS  III  requirements. 

The  oral  report  was  presented  to  the  steering  group  on  March  9,  1976,  and  the 
MITRE  reports  MTR-7521  and  MTR-7522  (references  3 and  4)  containing  information 
for  parts  1,  2,  and  3 of  the  specifications  for  enroute  facilities  were 
delivered  in  May  1977.  On  direction  from  the  steering  group,  specifications 
for  the  ARTS  III  facilities  were  not  prepared. 

The  specifications  were  prepared  to  provide: 

1.  Interface  with  the  PAM  of  the  CCC.  (Enroute  approach  2 described  earlier.) 

This  approach  is  the  least  expensive  and  takes  maximum  advantage  of  standard 
interface  hardware. 

2.  A graphic  display  capability  with  position  selection  (For  example:  track- 
ball, joy  stick). 

Although  this  course  of  action  involves  potentially  higher  hardware  costs,  a 
graphic  display  is  required  as  an  integral  part  of  the  facility  training 
function.  The  instructors  use  the  display  to  assess  the  total  traffic  situa- 
tion confronting  the  student  so  that  appropriate  modifications  to  the  traffic 
can  be  made  to  provide  special  problems  in  real  time.  In  addition,  the  graphic 
presentation  represents  the  least  departure  from  the  current  training  mode  and 
will  make  the  transition  easier,  as  well  as  providing  some  training  benefits 
to  controllers  acting  as  pilots. 

3.  Touch  panel  input. 

The  touch  panel  input  method  has  the  potential  for  reduced  input  error  and 
shortened  pilot  training  time  since  the  memorizing  of  message  composition  and 
format  is  at  a minimum.  Since  the  characteristics  of  the  graphic  display  such 
as  overall  size,  display  surface  curvature  and  thickness  can  constrain  the 
application  of  a touch  panel,  the  specifications  do  not  exclude  the  possibility 
of  a separate  tabular  display  for  the  touch  function.  A standard  keyboard  for 
complex  inputs  and  backup  will  be  considered. 

4.  A message  repertoire  which  will  accommodate  all  messages  acceptable  to, 
and  received  from,  the  DYSIM  program. 

The  specification  does  however,  assume  that  additional  changes  will  be  made  to 
DYSIM  which  will  output  target  speed  to  the  interface  processor,  allow  entry 
of  no-gyro  turns  (with  direction  of  turn  specified  but  without  a new  heading), 
allow  entry  of  a specified  direction  of  turn,  allow  a stop  turn  entry,  and 
allow  entry  of  a change  of  rate  of  ascent  or  descent  for  a given  aircraft. 

5.  Association  of  target  position  with  map  positions  for  selected  input 
messages. 
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The  time  when  this  decision  was  made  did  not  permit  time  for  specifying  all 
of  the  possible  applications  of  this  capability.  For  instance,  full  utiliza- 
tion of  the  look  ahead  ability  (allowing  entry  of  a message  defining  action 
at  a future  point)  is  not  included,  but  the  capability  will  be  there  for 
future  implementation. 


CONCLUSIONS 


1 


In  preparing  conclusions  and  recommendations,  it  was  assumed  that  although  the 
study  could  firmly  establish  the  technical  feasibility  of  providing  the  desired 
simulator  pilot  consoles,  the  decision  on  desirability  of  such  actions  was 
dependent  upon  additional  factors  beyond  the  scope  of  this  study,  and  within 
the  purview  of  the  steering  group.  The  conclusions,  therefore,  are  designed 
to  provide  as  much  information  as  possible,  which  will  aid  in  that  decision- 
making process. 

It  is  concluded  that: 

1.  It  is  feasible  to  develop  a more  cost  effective  pilot  simulator  type  con- 
sole within  the  guidelines,  design  objectives,  and  functional  requirements 
specified  by  the  working  group.  Operational  software  changes  amounting  to 
about  2 man-years  effort  are  required  to  interface  the  new  input  devices. 

2.  The  functional  specifications  prepared  under  this  project  are  adequate 
for  the  procurement  of  replacement  simulator  pilot  consoles  for  enroute  facili- 
ties in  the  continental  United  States.  EARTS  equipped  ARTCC's,  however,  can- 
not be  accommodated  with  the  enroute  specifications.  Specially  modified 
specifications  may  be  required. 

3.  The  simulator  pilot's  operating  capability  can  be  greatly  improved,  entry 
errors  can  be  reduced,  and  simulator  pilot  training  kept  to  a minimum  by  use 

of  a touch  panel  input  device,  a menu  list  designed  for  simulator  pilot  entries, 
and  with  software  in  the  new  interface  processor  which  provides  target/map 
association. 

4.  With  target/map  association  performed  by  the  software, 'a  graphic  display 
is  not  essential  for  the  simulator  pilot.  The  instructors,  however,  require 
a graphic  display  and  an  entry  capability,  similar  to  the  simulator  pilot's, 
in  order  to  visualize  and  modify  the  developing  situation  to  meet  the  indivi- 
dual needs. 

5.  Simulator  pilot  consoles,  as  specified,  can  provide  a means  for  additional 
enhancements  to  the  field  training  capability.  They  may  possibly  also  act  as 
the  base  for  a future  independent  training  function. 

6.  The  new  consoles,  as  stated,  cannot  be  placed  in  operation  in  less  than 

2 1/2  years.  Necessary  changes  to  DYSIM  and  ETG  must  be  allowed  to  take  place 
during  this  time.  These  changes  will  cause  a continuing  divergence  between 
existing  capabilities  and  the  specifications,  including  the  crucial  interface 
requirements.  Therefore,  an  immediate  update  after  delivery  or  continuing 
changes  durirg  development  must  be  assumed;  either  of  which  Will  further  delay 
the  field  implementation  date.  At  the  same  time,  new  operational  functions 
and  traffic  load  increases  can  be  expected  to  decrease  available  training  time 
and  limit  the  effective  life  of  the  field  training  capability.  The  new  con- 
soles by  themselves  will  not  affect  the  useful  life  of  the  present  system. 
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7.  Although  the  new  consoles  are  apparently  desired  to  accommodate  an  anti- 
cipated large  increase  in  the  amount  of  training,  it  is  not  probable  that  such 
an  increase,  with  the  present  operational  systems,  can  ever  be  achieved.  Such 
an  increase  requires  a significant  increase  in  track  processing  capacity. 
Approximately  9 man-months  of  reprogramming  effort  can  improve  the  simulated 
target  track  processing  time,  and  allow  some  increase  in  the  number  of  simu- 
lated tracks. 

8.  Partial  preliminary  information  indicates  that  the  training  staff  and 
availability  of  trainees  is  not  sufficient  to  support  the  amount  of  increased 
training  implied  by  the  guidelines  and  by  the  number  of  pilot  consoles  desired. 
That  is,  the  number  of  people  necessary  to  man  the  increased  number  of  pilot 
positions,  prepare  the  training  problems,  and  instruct  the  increased  number  of 
students  are  not  available  nor  anticipated.  Increased  staff  and  specially 
hired  simulator  pilots  may  be  necessary. 

9.  There  is  not  sufficient  physical  space  in  many  facilities  to  accommodate 
the  increased  number  of  consoles  indicated. 

10.  The  cost  cf  providing  114  consoles  at  20  enroute  facilities  and  NAFEC, 
as  specified,  is  approximately  $5.7  million  (or  about  $50,000  per  console), 
not  including  regional  costs  for  site  preparation  and  other  in-house  costs. 
Because  of  fixed  costs,  changes  to  the  number  of  sites  or  consoles  will  affect 
the  total  cost  at  the  rate  of  about  $85,000  per  site  plus  $20,000  per  console. 
Therefore,  variations  in  the  number  of  consoles  and  sites  are  necessary  and 
possible  to  keep  costs  within  the  budget.  For  instance,  55  consoles  at 

11  enroute  sites  would  cost  approximately  $3.7  million. 

11.  The  cost  of  providing  83  consoles  at  30  ARTS  III  facilities,  as  specified, 
is  approximately  $4.6  million  (or  about  $55,000  per  console),  not  including 
regional  costs  for  site  preparation  and  other  in-house  costs.  Changes  to  the 
number  of  sites  or  consoles  will  affect  the  total  cost  at  the  rate  of  about 
$42,000  per  site  plus  $20,000  per  console. 

12.  As  one  ARTS  III  horizontal  DEDS  can  accommodate  three  input  keyboards,  up 
to  three  simulator  pilots  could  support  a controller  trainee  at  another  display 
with  the  present  system  for  about  $33,000  per  simulator  pilot,  based  on  a DEDS 
cost  of  about  $110,000. 

13.  A complete  study  to  acquire  substantive  or  quantitative  data  regarding 
the  present  field  training  system  would  be  most  helpful  in  determining  the 
desirability  of  the  new  consoles,  but  it  will  take  9 months  to  1 year  to  com- 
plete, thus  further  delaying  the  procurement  and  reducing  the  useful  life. 
Further,  it  is  expected  that  such  a study  would  only  substantiate  and  quantify 
the  magnitude  of  the  anticipated  limitations  and  additional  costs  for  support, 
space,  and  revised  software. 
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RECOMMENDATIONS 


Regardless  of  the  decision  on  procurement  of  new  simulator  pilot  consoles,  it 
is  recommended  that: 

1.  The  reprogramming  of  the  enroute  track  processing  software  necessary  to 
improve  the  processing  time  and  relieve  the  simulation  target  track  capacity 
problem  (for  automatic  mode  targets)  be  done  as  soon  as  possible. 

2.  Action  be  taken  to  insure  that  the  present  field  training  capabilities 
are  enhanced  as  much,  and  as  soon  as  possible  by  reducing  the  time  for  process- 
ing the  pending  software  National  Airspace  System  (NAS)  Change  Proposals  (NCP) 
designed  to  improve  DYSIM  and  ETG.  Further,  that  action  be  taken  to  include 
NAFEC  in  the  process  in  order  to  maintain  currency,  to  evaluate  the  training 
effectiveness  of  the  NCP  and  to  ensure  that  consistency  is  maintained  with  the 
ever-evolving  training  capabilities. 

3.  The  planned  study  of  the  present  field  training  capabilities,  projected 
short  and  long  term  needs,  expected  life,  and  alternative  enhancements  or 
replacement  systems  be  started  immediately  and  completed  as  soon  as  possible. 

4.  Upon  completion  of  the  study,  action  should  be  taken  to  design  and  procure 
a field  training  capability  adequate  to  meet  the  total  field  training  needs  as 
envisioned  from  the  study. 
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APPENDIX  A 


AAD-1  LETTER  TO  AED-1,  ASSISTANCE  REQUIRED  IN  DEVELOPMENT  OF 
ATCS  TRAINING,  DATED  JULY  14,  1975 


DATE: 

IN  REPLY 
REFER  TO: 

SUBJECT: 

FROM: 

TO: 


DEPARTMENT  OF  TRANSPORTATION 

FEDERAL  AVIATION  ADMINISTRATION 


JUL  2 4 JQ7C  WASHINGTON,  D.C.  20991 


Assistance  Required  in  the  Development  of  ATCS  Training 


Associate  Administrator  for  Administration,  AAD-1 

Associate  Administrator  for  Engineering  and  Development,  AED-1 

Recent  investigations  and  evaluations  have  revealed  a substantial 
inadequacy  in  the  Air  Traffic  Controller  Training  Program.  To  correct 
the  identified  deficiencies,  the  Office  of  Personnel  and  Training,  in 
concert  with  the  Air  Traffic  Service,  is  presently  engaged  in  an  effoit 
to  develop  a revised  terminal/enroute  training  program. 

During  the  development  effort,  it  became  apparent  that  in  order  to 
assure  successful  implementation  of  the  program  and  meet  the  stated 
objectives,  additional  resources  and  development  actions  would  be 
required. 

In  response  to  the  above  and  to  a need  suggested  in  the  IDA  study,  you 
established  an  AED  working  group  on  ATCS  training  which  has  been  ex- 
ploring areas  in  which  your  office  could  most  actively  support  Personnel 
and  Training  in  their  effort.  As  a result  of  their  meetings,  the  group 
has  determined  that  the  areas  in  which  your  assistance  would  provide  the 
most  immediate  benefit  are: 

1.  Academy  Simulation 

a.  Development  of  engineering  specifications  for  Academy  radar 
simulation  according  to  the  attached  training  requirements 
and  schedule. 

b.  Providing  technical  assistance  to  the  Aeronautical  Center, 
which  I believe  should  be  the  Requiring  Activity,  in  their 
procurement  of  the  simulation  system  for  the  Academy. 

2.  Identification  and  development  of  improvements  to  field  radar 
simulation  which  should  be  completed  by  January  1,  1976,  to  provide 
lead  time  for  FY-78  budget  programming.  This  should  include  as 

a minimum. 

a.  functional  enhancements; 

b.  scenario  development,  tape  input  and  adaption; 

c.  engineering  specifications  for  pilot  consoles; 

d.  future  enhancements  necessary  to  provide  complete  and 
total  simulation  of  the  operational  environment. 

3.  Immediate  assistance  in  the  completion  of  CODE  development. 
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4.  Coordination  with  AAM,  CAMI,  TSC  and  NAFEC  in  the  continued 
development  of  Controller  Performance  Measurements  (CPM)  which 
would  accurately  identify  controller  progress  during  the  various 
phases  of  his/her  training.  The  action  should  be  completed  by 
January  1,  1976,  as  stated  in  the  proposed  Air  Traffic  Controller 
Training  Program  completion  schedule.  (Copy  attached). 

5.  Development  of  a capability  for  simulation  training  at  the  ARV'S  II 
facilities,  VFR  Towers  and  Non-NAS  centers.  In  order  to  prepare 
this  for  submission  in  the  FY-78  Budget,  I suggest  a completion 
date  of  January  1,  1976. 

While  seeking  your  immediate  and  active  support  in  the  areas  enumerated 
above,  I in  no  way  mean  to  infer  that  this  is  the  total  support  you 
could  render.  For  instance,  immediate  and  on-going  expansion  of  co- 
ordination and  communication  with  the  Office  of  Personnel  and  Training 
regarding  those  E&D  programs  which  have  a direct  impact  on  operational 
or  maintenance  training  would  be  most  beneficial.  Some  areas  which 
should  be  considered  are  your  developmental  and  research  efforts  con- 
cerning FSS,  DABS,  MLS/RNAV/M&S,  ICS  and  WVAS.  To  accomplish  this,  I 
suggest  retention  of  the  E&D  Working  Group  as  a permanent  interoffice 
activity.  Should  you,  or  the  working  group,  determine  other  methods  of 
assistance,  the  arrangement  for  action  upon  them  would  be  greatly 
appreciated. 


Enclosure 
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APPENDIX  B 


LETTER  REPORT,  NA-76-43-LR,  LOW-COST  ATCS  TRAINING  PILOT  SIMULATOR  CONSOLE 
FOR  FIELD  FACILITIES,  DATED  AUGUST  26,  1976 


August  26,  1976 

Letter  Report,  NA-76-43-LR, 

Low-cost  ATCS  Training  Pilot 
Simulator  Console  for  field  Facilities 

Director,  ANA-1 
ARD-1 

This  report  was  prepared  by  William  JDunn  and  Kenneth  House,  ANA -230. 

It  is  an  interim  report  on  the  work  underway  under  project  216-103-010, 
Simulator  Pilot  Consoles  for  NAS  Qaroute  and  ARTS  ID  Facilities,  in 
NAFXC  Program  21-279,  ATCS  Personnel  Support 

Background 

Operational  displays  costing  about  $100,  000  are  presently  used  in  the 
facility  training  configuration  by  both  the  ATCS  trainee  and  at  the  pilot 
simulator  position  supporting  the  training.  Only  the  trainee  needs  an 
operational  unit.  NAFEC  was  requested  to  investigate  the  feasibility  and 
desirability  of  providing  a special  purpose  pilot  simulator  console  to 
replace  the  operational  consoles  now  used  for  that  purpose.  Alternatives 
under  Investigation  include:  (1)  a new  cheaper  display  that  could  perform 
all  functions  of  the  present  operational  display,  (2)  commercially  avail- 
able terminal  consoles  with  a tabular  display  and  keyboard,  interfaced 
with  the  central  computer  through  a minicomputer,  and  (3)  separate  target 
generation  capability  for  each  site  or  for  multiple  sites  from  a central  or 
regional  location. 

Because  of  the  cost  and  time  implicit  in  the  above  alternatives,  NAFCC 
was  requested  to  investigate  the  possibility  of  providing  a low  cost,  quick 
solution,  such  as  using  a closed  circuit  TV,  to  provide  the  pilot  with  a 
picture  of  the  trainee's  display.  The  TV  approach  was  investigated  and 
found  to  be  infeasible,  primarily  becaaae  of  the  problems  regarding  cam- 
era location,  stability  of  lighting,  etc.  The  display  being  monitored  is 
also  being  used  by  the  trainee  and  cannot  be  reasonably  screened.  The 
camera  must  also  be  at  sufficient  distance  to  include  the  whole  display  in 
the  picture.  This  introduces  reflections  and  reduces  resolution  below 
adequate  levels. 

However,  on  the  assumption  that  such  a reproduction  of  the' trainee's 
display  would  be  adequate  for  the  simulator  pilot,  and  that  the  simulator 
pilot  display  requires  no  capability  of  its  own,  another  alternative  was 
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investigated.  This  method  incorporates  a "slave"  display,  which  would 
receive  all  its  drives  and  video  from  the  hoet  display.  The  details  of 
our  study  of  this  quick,  low-cost  approach  are  enclosed. 

Conclusions: 

1.  A TV  presentation  of  the  trainee's  display  for  use  by  the 
simulator  pilot  is  not  feaeihle. 

2.  Contrary  to  the  original  assumptions  in  the  enroute  system, 
the  simulator  pilot  requires  a different  display  than  the  trainee.  Also, 
the  entry  capability  available  to  the  pilot,  after  removal  of  the  opera- 
tional console,  is  Inadequate  for  the  actions  desired  and  will  require 
software  changes.  The  slaved  display  approach  is,  therefore,  not 
feasible  for  enroute  facilities. 

3.  The  total  cost  of  Implementing  the  slaved  display  approach, 
with  a sole-source  contract  to  Orwin.  is  approximately  $20,  000  for 
the  enroute  and  $22,  000  for  the  ARTS  m,  one-time  charges,  plus  an 
additional  $6,  000  per  display.  If  implemented  only  in  the  ARTS  111 
system,  the  sole  source  accessibility  of  Orwin  Corporation  to  design 
the  interface  and  build  and  install  the  displays  would  be  questionable. 

Costs  would  undoubtedly  increase.  The  slaved  display  approach  is, 
therefore,  not  considered  as  desirable  for  ARTS  m sites. 

R e commendation: 

It  is  recommended  that  we  proceed  immediately  toward  determining 
the  feasibility  of  a pilot  simulator  subsystem  for  the  field  facilities, 
which  is  compatible  with  long-term  reqkirements  and  which  will  also 
provide  for  improvements  to  training  effectiveness,  rather  than 
pursuing  further  a quick,  low-cost  temporary  solution. 

If  further  information  on  this  project  is  desired,  please  contact  the 
NAFEC  Program  Manager  for  NPD  21-279,  Mr.  Kenneth  House,  ANA-230, 
or  Mr.  William  Dunn,  ANA-230. 


■ khi-  a . l M . , 'e, 

^ROBERT  L.  FAITH 
Enclosure 

ANA-4,  ANA-64,  ANA-523,  ARD-54,  ARD-150. 
ANA  -230:KHouae:lm:x2764:8/l6/  76 
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ENCLOSURE 
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Quick  Low-cost  Pilot  Simulator  Study 
The  Slave  Display  Characteristics 

A slave  presentation  remoted  50  feet  can  be  provided  which  would 
have  sufficient  resolution  and  bandwidth  to  allow  reading  of  alpha- 
numerics  without  difficulty.  The  enroute  and  terminal  slave  displays 
would  be  identical  except  for  tube  phosphor.  It  would  use  a rectang- 
ular tube  with  a useful  area  of  about  14"  x 14".  If  necessary, 
compensation  can  be  applied  to  the  remoted  video  and  drive  signals  to 
provide  for  the  differences  in  characteristics  between  the  slave  and  its 
host  display.  The  host  display  will  not  be  degraded  by  either  the 
presence  or  absence  of  a slave  display.  The  failure  of  a slave  display 
will  not  affect  the  performance  of  the  host  display. 

To  obtain  a slave  display  it  will  be  necessary  to: 

1.  Identify  the  video  and  deflection  circuitry  interface  points 
and  document  them. 

2.  Build  interface  and  isolation  amplifiers. 

3.  Document  the  cabling  and  mounting  requirements  in  sufficient 
detail  that  will  allow  FAA  technicians  to  cable  and  mount  the  isolation 
and/or  driver  amplifiers.  These  amplifiers  will  have  their  own  power 
supplies  and  be  independent  of  the  host's  present  circuitry.  If  the  isola- 
tion and/or  drive  amplifiers  are  mounted  outside  the  FAA  host  display, 
their  mounting  would  be  the  contractor's  responsibility,  at  least,  for 
the  first  units. 

4.  Plug  in  and  remote  the  new  display  some  50  feet  and  faith- 
fully reproduce  the  host  picture  on  the  slave  display. 

5.  Build  and  install  the  new  display. 

6.  Prepare  a description  of  interface  points,  cable  and  plug 
schematics,  isolation  and  drive  amplifiers  circuitry  and  parts  in 
sufficient  detail  to  allow  a procurement  under  competitive  bid  to  be 
written  by  FAA  for  a quantity  buy  of  slave  displays. 
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A Method  for  Accomplishment 


Orwin  would  be  the  company  we  would  recommend  to  perform  all  the 
above  actions  except  those  items  named  in  Item  3 to  be  accomplished 
by  FAA  technicians.  Orwin  is  a two-man  company  with  a record  of 
production  for  FAA  of  like  items;  e.  g.  , the  design  of  the  new  deflection 
system  for  the  Plan  View  Display  (PVD).  This  system  has  been 
successful  and  demonstrates  a 35-percent  reduction  in  the  power  used 
by  the  NAS  enroute  displays.  At  the  same  time,  the  PVD's  excellent 
performance  characteristics  were  maintained. 

Their  knowledge  of  deflection  and  video  circuitry  would  allow  them  to 
transfer  their  PVD  slave  solution  to  the  terminal  display  thus  using  the 
same  slave  display  (except  for  the  phosphor)  in  both  areas.  The  risk 
of  failure  to  produce  an  enroute  display  would  be  zero.  For  the  terminal 
display,  there  is  a risk  that  the  task  would  take  longer  to  accomplish 
than  desired.  There  is  no  risk  of  failure  to  produce  a terminal  slave 
display.  However,  the  deflection  and  video  amplifiers  in  the  terminal 
area  differ  from  those  of  the  enroute.  There  is  then  a risk  that  an 
unforeseen  problem  may  arise  that  will  cause  some  delay  in  achieving 
an  acceptable  solution.  Though  there  is  little  or  no  risk  of  failure, 
there  is  still  an  advantage  if  this  approach  is  pursued,  in  solving  the 
logistics  of  the  two  cases  at  NAFEC.  This  would  provide  the  least 
upset  of  an  operational  environment  and  yet  allow  the  displays  to  be 
transferred  to  a field  site  after  a successful  demonstration.  These 
displays  would  be  solid  state  and  need  the  absolute  minimum  of  additional 
display  circuitry.  Maintenance  is  at  the  card  substitution  level  thus 
requiring  little  maintenance  support. 

Cost  and  Time  to  Accomplish 


On  the  assumption  that  "ORWIN"  does  perform  the  task,  the  following 
costs  can  be  predicted:  For  the  enroute  system,  $20,  000;  for  the 
terminal  system,  $22,  000.  These  costs  include  a display  and  documen- 
tation sufficient  for  the  console  modification  by  an  FAA  technician  as 
proposed  in  item  3 and  for  the  documentation  to  satisfy  the  other 
listed  items.  It  also  includes  a successful  system  demonstration  of  the 
slave  display  at  a location  some  50  feet  from  the  host  display.  The  time 
to  accomplish  the  task  is  predicted  to  be  120  days.  This  is  broken  down 
as  follows:  90  days  to  the  delivery  of  the  enroute  display  and  the  cable 
change  documentation  and  parts  for  the  modification  of  a PVD.  After  the 
cabling  and  installation  of  the  display  the  system  would  be  demonstrated. 
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An  additional  30  days  is  needed  for  the  delivery  of  a like  package 
to  the  terminal.  The  time  of  120  days  is,  of  course,  after  "Receipt 
of  Contract.  " The  building  of  the  additional  displays  is  estimated 
to  cost  $6,  000  each  based  on  a 100-display  buy.  Since  the  display 
is  a commercially  available  one  and  the  cabling  modifications  to 
the  FAA  displays  are  to  be  done  by  FAA  technicians,  then  the  time 
to  delivery,  after  contract,  would  be  minimal. 

Simulator  Pilot  Input 

In  order  to  keep  the  cost  down  and  to  preclude  impact  on  the  present 
software,  the  use  of  present  operational  input  devices  was  assumed. 
In  the  ARTS  III  system  each  display  is  equipped  with  up  to  three  key- 
boards, one  of  which  is  used  by  the  pilot  in  the  training  configuration. 
Therefore,  with  this  slaved  approach  the  pilot  would  continue  to  use 
one  of  the  keyboards  associated  with  the  trainee  position. 

The  enroute  area  posed  different  problems.  The  trainee  and  pilot 
use  totally  separated  but  identical  keyboards,  Computer  Readout 
Device's  (CRD)  and  category /function  devices.  Our  contacts  with 
AFS  have  indicated  that,  whereas,  it  is  feasible  to  physically  mount 
these  devices  separate  from  the  PVD  consoles,  there  are  not,  in 
fact,  any  such  devices  available  for  such  use.  D (manual  controller) 
position  CRD's  and  keyboards  are  available  at  each  pilot  position. 

In  order  to  use  these  for  simulator  pilot  input,  however,  software 
changes  are  required.  These  changes  were  characterized  by  IBM 
as  being  "relatively  minor.  " 

Operational  Impact 

The  ARTS  III  Enhanced  Target  Generation  (ETG)  system  presently 
uses  the  same  display  for  both  the  trainee  and  pilot,  therefore,  there 
does  not  appear  to  be  any  operational  impact  involved  in  slaving  the 
trainees'  display  and  using  one  of  the  keyboards  associated  with  the 
trainees'  display  for  the  pilot.  Physically,  the  pilot  and  trainees 
could  then  be  separated  by  up  to  50  feet.  The  fact  that  the  trainees' 
display  would  also  contain  the  pilot's  preview  area  does  not  appear 
to  be  significant.  If  required,  the  pilot's  preview  area  could  be 
covered. 

In  the  enroute  system,  however,  other  problems  exist,  in  addition 
to  the  need  for  software  changes  indicated  above,  which  make  this 
approach  questionable,  if  not  unacceptable. 


1.  Operationally,  using  the  D position  eliminates  the  category/ 
function  capability  available  at  the  R (Radar)  position.  Even  with  the 
software  changes  the  pilots  entry  requirements  will  be  more  lengthy 
and  cumbersome,  thus  reducing  the  number  of  targets  he  can  control 
effectively.  The  lack  of  the  trackball,  although  not  considered  impor- 
tant, may  further  decrease  his  capability. 

2.  The  original  assumption  that  the  pilot's  display  required  no 
capability  separate  from  the  trainees'  was  found  to  be  incorrect.  The 
pilot  requires  constant  heading  and  altitude  information,  a special 
simulator  target  identification  and  manual/ automatic  indicator  not 
displayed  at  the  trainee's  position.  Thus,  if  this  approach  is  imple- 
mented, the  DYSIM  software  must  be  further  modified  to  output  this 
information  for  each  simulator  target  on  the  appropriate  pilot's  CRD. 

In  either  case,  this  approach  will  use  the  basic  DYSIM  and  the  ARTS  III 
Enhanced  Target  Generator  (ETG)  programs  as  presently  planned.  No 
special  capabilities  will  be  available  for  enhancement  of  these  systems 
beyond  those  possible  at  the  present  time. 
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APPENDIX  C 

ARD-152  LETTER  TO  AAT-14.2,  APT-310,  AAF-610  AND  ANA-230,  SIMULATOR 
PILOT  CONSOLES  FOR  ENROUTE  AND  ARTS  III  ATC  FACILITIES,  DATED  AUGUST  24,  1976 


DEPARTMENT  OF  TRANSPORTATION 

FEDERAL  AVIATION  ADMINISTRATION 


OATE: 

iN  REPLY 
Rt*LN  TO: 

SUBJECT 


August  24,  19  76  Washington,  u.c 

ARD-150  0 

Simulator  Pilot  Consoles  ior  En  Route  and  ARTS  Hi  Al’C  Facilities  \ 


fhom  Acting  Chief,  Training  Requirements  and  Performance  Evaluation 
Section,  ARD-152 

T0:  AAT-14.2,  APT-310,  AAF-610,  ANA-230 

To  support  the  SRDS/NAFEC  effort  of  investigating  the  feasibility 
and  desirability  of  replacing  En  Route  and  ARTS -II. I radar  displays 
(currently  being  used  «s  "target  operator  positions")  with  simulator 
pilot  consoles,  the  enclosed  developmental  guidance  was  developed 
by  representatives  from  AAT,  APT,  AAF , and  ARD.  It  is  recognized 
that  during  the  course  of  this  developmental  activity  it  may  become 
necessary  to  modify  these  design  guidelines,  functional  requirements 
and  design  objectives,  therefore,  it  is  recommended  that  this 
working  group  be  retained  as  interoffice  coordinators. 


I '' , 
/yY/S  l V K 
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SIMULATOR  PILOT  CONSOLES  FOR  ENROUTE 
ANL)  ARTS  III  ATC  FACILITIES 
(SRDS  SUBPROGRAM  216-103) 

BACKGROUND 

The  FAAs  newly  upgraded  ATCS  training  program  stipulates  that  after 
graduation  from  the  Academy,  the  developmental  controller  will  receive 
advanced  environmentally  oriented  radar  training  at  the  Air  Traffic  Control 
facility.  This  requirement  will  be  satisfied  through  the  use  of  the  ATC 
facility  simulation  programs  - DYSIM  in  EnRoute  and  ETC  in  ART:.  III. 

An  integral  part  of  the  simulation  program  is  the  simulator  pilots  who  in 
response  to  the  controllers  instructions  "fly"  the  simulated  radar  tar:  t t 
An  operational  radar  console  (PVD)  is  used  for,  each  psuedo  pilot  position 
in  the  EnRoute  facility  while  at  the  ARTS  III  locations,  the  pilots  share 
the  radar  display  with  the  ATCS  trainee.  In  the  latter  situation,  a 
separate  keyboard  is  provided  for  use  by  the  simulator  pilot.  The  cost 
and  need  of  the  radar  consoles  is  high  and  the  keyboard  which  was  not 
designed  for  simulator  pilot  inputs  is  cumbersome  and  time  consuming. 

The  availability  of  the  radar  training  program,  including  scheduling  and 
equipment  (consoles)  is  dependent  on  the  real-time  operational  situation 
at  the  facility. 

OBJECTIVE 

The  objective  of  this  effort  is  to  investigate  the  feasibility  and 
desirability  of  replacing  the  existing  operational  radar  displays  that 
are  being  used  for  pilot  consoles  during  training  exercises.  The  study 
will  also  consider  improved  techniques  for  entering  pilot  messages.  If  these 
studies  indicate  the  practicability  of  introducing  new  simulator  pilot 
consoles,  then  SRDS  will  develop  the  required  functional  specifications 
which,  when  further  developed  by  AAF,  will  lead  toward  the  procurement  and 
implementation  of  the  pilot  position  equipment. 

DESIGN  GUIDELINES 

The  FY-78  budget  provides  a funding  item  for  procurement  of  the  simulator 
pilot  consoles  for  the  EnRoute  facilities.  It  is  anticipated  that  the 
simulator  pilot  consoles  for  the  ARTS  III  facilities  will  be  included  in 
the  FY-79  budget.  Based  on  this  action,  the  NAFEC  feasibility/cost  study 
and  the  functional  specification  development  (if  deemed  necessary)  will 
initially  concentrate  on  the  EnRoute  pilot  console  situation  with  the 
ARTS  III  to  follow  shortly  thereafter. 

Recognizing  the  need  to  provide  developmental  guidance,  a working  group, 
consisting  of  representatives  from  AAT,  APT,  AAF  and  ARD  developed  the 
following  design  guidelines  for  the  EnRoute  and  ARTS  III  pilot  consoles. 

1.  Modifications  to  the  existing  operational  hardware  i.e.,  PVDs , DEDs , 

CRDs,  keyboards  are  not  acceptable. 
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2.  It  is  highly  desirable  that  no  modification  be  made  to  the  current 
operational  system  software.  Minor  modifications  to  the  DYSIM  and  ETG 
simulation  program  to  accommodate  the  pilot  console  and/or  to  enhance 
keyboard  entries  arc  acceptable. 

* 

3.  A standard  system  interface,  preferably  through  the  EnRoute  GPI/GPO 
and  the  ARTS  III  ESI,  should  be  provided. 

4.  -A  separate  pilot  console  recording,  in  addition  to  that  already 

provided  by  the  EnRoute  SAR/DART  and  ARTS  III  data  extractor  program 
is  not  required. 

5.  During  facility  training  exercises,  the  pilot  position  will  also 
function  as  a ghost:  position  - initiating  and  accepting  both  verbal 
and  automated  handoffs,  coordinating  flight  pi  an' information , etc. 

6.  Communications  for  the  pilot/ghost  position  is  not  a part  of  this 
developmental  task.  Provisions  for  mounting  of  communication 
selector  panels,  volume  controls  and  headset  jacks  should  be  considered 
in  the  design  of  the  pilot  console. 

7.  The  overall  physical  dimensions  of  the  pilot  console  must  not  exceed 
those  of  the  existing  operational  radar  displays. 

a.  EnRoute  PVD  - 51.5"  high,  35.5"  wide,  54.5"  deep. 

b.  ARTS  III  DED  - 48"  high,  30"  wide,  56"  deep. 

8.  A closed  circuit  television  system  is  not  an  acceptable  design 
approach  for  the  pilot  console. 

DESIGN  OBJECTIVES 

The  pilot  console  hardware  including  the  display,  keyboard  and  housing 
should  be  common  for  both  EnRoute  and  ARTS  III  facilities.  The  console 
must  be  a self  supporting  unit  that  can  easily  and  rapidly  be  replaced. 
Electrical  connectors  that  are  readily  accessable  and  provide  a quick 
change  capability  is  a highly  desirable  requirement. 

2.  The  application  of  sound  human  engineering  used  in  the  design  of  the 
pilot  console  i.e.,  heigth  and  angle  of  the  display,  configuration 
of  the  keyboard,  display  filters,  is  a manditory  design  objective. 

3.  To  improve  the  simulator  pilots  operating  capability  the  keyboard 
Inputs  must  be  simplified.  An  analysis  of  existing  DYSIM  and  ETG  input 
methods  and  their  associated  limitations  is  a prerequisite  for  the  design 
of  the  pilot  console  keyboard. 

4.  Limited  funds  for  this  effort  dictates  that  the  cost  of  the  pilot 
console  (hardware  and  software)  remain  low. 


FUNCTIONAL  REQUIREMENTS 


Some  of  the  functional  requirements  that  will  substantially  contribute 
to  the  overall  analysis,  design  and  development  of  the  pilot  console  are 
listed  below. 


ARTCC  ARTS  III 

Desired  # of  targets  per  pilot  console  10-12  10-12 

Maximum  # of  pilot  consoles  per  facility  16  8 

Maximum  # of  student  consoles  per  facility  8 6 

Maximum  # of  targets  per  student  console  25  16 

Ratio  of  pilot  console  to  student  console 

Normal  training  mode  2:1  2:1 

Maximum  mode  Flexible  Flexible 


Enhancements  to  the  ETG  or  DYSIM  program  such  as  freeze,  backup  and  replay 
are  not  considered  a part  of  this  task,  however,  provisions  for  these 
capabilities  will  be  considered  and  incorporated  as  they  apply  to  the 
pilot  console  only.  An  example  of  this  would  be  providing  a "freeze" 
key  on  the  pilot  console  keyboard  but  not  developing  the  software  to 
provide  this  capability.  Note  - ARTS  III  facilities  recently 

incorporated  the  "freeze/restart"  capabilities  into"  the  ETG  program  which 
indicates  that  a freeze  key  on  the  pilot  console  keyboard  is  a valid 
requirement . 

If  after  review  of  the  NAFEC  feasibility/cost  study,  a decision  is  made  to 
proceed  with  the  procurement  of  a specific  simulation  pilot  console,  SRDS/ 
NAFEC  will,  by  April  1,  1977,  develop  the  required  functional  specification. 
The  FAA  Specification  for  VIIF  Direction  Finders  dated  August  1,  1975, 
shall  be  used  by  as  a representation  of  the  specification  that  AAF  needs 
by  April  1,  1977,  if  they,  are  to  commit  FY-78  funds  for  the  EnRoute  pilot 
consoles. 


Members  of  the  working  group  that  assisted  in  the  development  of  these 
design  guidelines,  functional  requirements  and  design  objectives  for  the 
simulation  pilot  consoles  are'  listed  below.  It  is  strongly  recommended 
that  this  group  be  retained  as  an  interoffice  coordination  activity  for 
the  duration  of  this  program. 
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COMPARISON  OF  DYSIM  AND  ETG  SIMULATOR  PILOT  FUNCTIONS 

A comparison  of  the  simulator  pilot  functions  was  made  as  performed  using  DYSIM 
and  ETG.  The  functions  compared  are  those  data  entries  that  ordinarily  are  made 
from  the  simulator  pilot  positions,  in  a training  simulation,  to  manipulate  the 
movement  of  individual  targets.  Additional  actions  are  also  performed  by  the 
simulator  pilot  in  his  role  as  a controller  of  an  adjacent  position  to  the 
trainee  controller's  position  (ghost  controller  functions).  These  functions 
(hand-off  and  accept  hand-off,  primarily)  are  operational  type  functions,  rather 
than  simulation  functions,  and  are  not  considered  in  this  comparison.  There  are 
also  other  DYSIM  and  ETG  functions  performed  by  the  training  staff  from  their 
input/output  typewriter  positions  to  set  up  and  control  the  total  training 
environment.  These  also  are  not  dealt  with  in  this  comparison.  Detailed 
functional  descriptions  of  DYSIM  and  ETG  may  be  found  in  NAS  Model  A3d2  and 
ARTS  III  specifications  and  handbooks. 

In  the  following  comparison,  the  specific  keyboard  entries  related  to  the 
function  are  shown  first,  followed  by  a comparison  analysis  of  the  similarities 
and  differences  between  DYSIM  and  ETG  for  that  function.  In  the  DYSIM  entries, 
the  first  key  depressed  is  the  specific  function  key  (START,  SPEED,  HEADING, 
etc.)  in  the  simulation  category  on  the  enroute  category/function  keyboard, 
followed  by  the  appropriate  fields  of  data  indicated.  The  last  message  field 
is  the  simulated  aircraft  identification  (coded  below  as  SAID  or  SFID  in  the 
entries).  In  ETG  entries,  the  first  key  depressed  is  the  F15  key,  identifying 
the  entry  as  an  ETG  message.  This  is  followed  by  the  target  identification 
(TG  in  the  comparison)  and  the  appropriate  fields  of  data  indicated.  In  both 
cases,  an  ENTER  key  depression  enters  the  completed  message  into  DYSIM  or  ETG 
for  action. 

A lower  case  "d"  in  the  following  entries  depicts  a digit  (0-9)  and  a paren- 
thesis around  a field  identifies  it  as  an  optional  field.  Upper  case  letters 
(or  groups  of  such  letters)  identify  specific  keys  on  the  keyboard.  Further 
descriptions  of  the  specific  entries  are  included  with  the  appropriate  functions. 
Commas  are  used  to  separate  the  fields  and  are  not  a part  of  the  entry. 


SPEED  FUNCTION 


SPEED,  dddd,  SFID,  ENTER 


dddd  - Ground  speed  in  knots  (kn) 


(F15),  TG,  V,  ddd,  (/ddd),  (d),  ENTER 


Legend 


V - Speed  Message 
ddd  - Ground  speed  in  knots 
(/ddd)  - Final  speed  when  initiating 
a target  with  increasing  or  decreasing 
speed. 

(d)  - Rate  of  change  (numeral  0-5) 


Analysis 


Four  speed  digits  are  required, 
leading  zeros. 


Three  speed  digits  are  required.  Maxi- 
speed permitted  is  500  kns. 


Speed  changes  are  made  at  a uniform,  Speed  changes  are  made  at  45  kns/ 


randomly  selected,  rate  of  .5, 

1.0,  or  1.5  kns/s.  Speed  changes  may 
be  automatic,  as  discussed  under 
Hold  Function. 


minute  unless  a different  rate  code 
is  entered : 

0- 45  kns/min  3-90  kns/min 

1- 60  kns/min  4 - 120  kns/min 

2- 75  kns/min  5 - 225  kns/min 


If  a speed  instruction  is  entered 
while  the  flight  is  in  a holding 
pattern,  the  input  will  be  rejected. 

If  a speed  instruction  is  entered 
while  the  flight  is  in  a turn,  the 
turn  will  be  completed  before  the 
speed  change  occurs. 


BEACON  FUNCTION 

I 

Entry 

BEACON,  (dddd),  (C),  (I),  SFID,  ENTER  (F15) , TG,  B,  (dddd),  (Ad),  (W) , (I), 

ENTER 


Legend 


dddd  - Octal  digits 
C - Turn  on/off  Mode  C 


B - Beacon  Message 
dddd  - Octal  digits 
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DYSIM 

ETG 

I - Squawk  Ident. 

Ad  - Key  followed  by  a digit  (0-3)  to 

effect  Mode  3A  validity. 

W - To  effect  weak  target 

I - Squawk  Ident. 

Analysis 


A separate  Code  Reliability  Index 

Mode  3A  validity  is  controlled  by  this 

(CRI)  Function  controls  Mode  3A 

function 

validity. 

Mode  C may  be  turned  on  or  off 

Mode  C emissions  are  controlled  by  the 

Altitude  Function 

Weak  target  ability  is  not  available 

A weak  target  may  be  specified 

ALTITUDE  FUNCTION 

I 

Entry 


ALTITUDE,  ddd,  SFID,  ENTER 


| (F15) , A,  ddd,  (/ddd),  (d),  (d),  ENTER 

Legend 


ddd  - Altitude  in  hundreds  of  feet 


A - Altitude  Message 

ddd  - Altitude  in  hundreds  of  feet 


(/ddd)  - Final  altitude  when  initiating 
a target  climbing  or  descending 

(d)  - Change  rate  (numeral  0-3) 


(d)  - Mode  C validity  (numeral  0-3) 
Analysis 


Rate  of  climb  or  descent  is  obtained 
from  the  aircraft  characteristics 
table.  In  order  to  change  the  rate, 
the  pilot  must  move  to  the  D position 
keyboard  and  change  the  type  of  air- 
craft by  entering  a flight  plan 
amendment  message. 

Mode  C off/on  capability  is  part  of 
the  Beacon  Function 


Rate  of  climb  or  descent  is  at 
750  feet  per  minute  (fpm)  unless  a 
different  rate  code  is  entered: 

0- 375  fpm 

1- 750  fpm 

2- 1500  fpm 

3- 3000  fpm 

Mode  C validity  may  be  established  by 
entry  of  the  validity  code,  0-3, 
representing  mode  C through  validity 
level  3,  respectively. 
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DYSIM 


ETG 


HEADING  FUNCTION 


I 


Entry 


HEADING,  ddd,  (R) , SFID,  ENTER 


(F15) , TG,  H or  HL  or  HR,  ddd,  (/ddd), 
(d),  ENTER 


Legend 


ddd-Magnetic  heading  in  degrees 
(R)  - Intercept  route 


H - Heading  Message 
R - Right  turn 
L - Left  turn 

ddd  - Magnetic  heading  in  degrees 
(/ddd)  - Final  heading  when  initiating 
r target  turning 
(d)  - Change  rate  (numeral  0-7) 


Analysis 


Direction  of  turn  can  not  be  specified, 
The  target  automatically  turns  in  the 
direction  requiring  the  smallest  turn 
to  reach  the  new  heading.  When  the 
longer  direction  of  turn  is  specified 
by  the  controller,  the  pilot  must  make 
two  heading  entries  to  lead  the  target 
around  in  the  desired  direction. 

The  turn  rate  is  3°/s  if  ground  speed 
is  210  kn  or  less,  otherwise  the  rate 
is  gradually  reduced  as  the  ground 
speed  increases. 


Entry  of  optional  code  R will  cause  the] 
simulation  flight  to  change  to  the 
automatic  mode  when  intercepting  the 
converted  route. 

A target  cannot  be  initiated  which  is 
in  a turn. 


Direction  of  turn  may  be  specified. 
Target  will  turn  in  direction  requir- 
ing the  smallest  turn  if  direction  is 
not  specified. 


Turn  rates  are  nominal  values  based  on 
ground  speed,  unless  a different  rate 
code  is  entered: 


0- 1 °/s. 

1- 1.5°/ s. 

2- 2°/ s. 

3- 3 °/s. 


4- 4°/s. 

5- 5°/s. 

6- 6°/s. 
1-1°  I s . 


ETG  does  not  store  route-of-f light , 
and  therefore,  does  not  have  an  auto- 
matic mode. 


A target  may  be  initiated  in  a turn  by 
entry  of  two  headings  (initial  and 
desired) . 
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DYSIM 


ETG 


None 


NO- GYRO  TURN 

I 

Entry 

(F15) , TG,  L or  R or  F or  G or  T,  ENTER 
Legend 

L - Standard  rate,  left  turn 
R - Standard  rate,  right  turn 
F - 1/2  standard  rate,  left  turn 
G - 1/2  standard  rate,  right  turn 
T - Stop  turn 


Analysis 


A target  cannot  be  turned  without  a 
new  heading.  Direction  of  turn  is 
is  automatic  (Heading  Function). 

This  function  can  be  fabricated  by 
using  the  Heading  Function,  selecting 
a nominal  heading  to  cause  a turn  in 
the  desired  direction,  entering  addi- 
tional heading  changes  as  required  to 
continue  the  turn,  and  stopping  the 
turn  by  entering  a heading  change  con- 
taining the  present  heading  shown  in 
the  data  block. 


This  function  will  initiate  a turn  at 
the  rate  and  in  the  direction  defined 
in  the  message  without  final  heading. 
The  turn  will  continue  until  this 
message  is  again  entered  using  the  stop 
turn  indicator. 


DYSIM 


ETG 


HOLD  FUNCTION 


I 


Entry 


HEADING, H(L) , (dd(D) ) , (*), SFID, ENTER 


(F15) ,TG,HHS  or  HRHS  or  HLHS , 
(d),  ENTER 

or 

(F15)  Y,S 


Legend 


H - Hold 


(L)  - Left  turns  (otherwise  right  turns 
are  made) 

(dd)  - Leg  length  in  minutes  or 
(dd(D))  - Leg  length  in  miles 


(*)  - Maintain  existing  speed. 

(If  * is  not  entered,  maintain  current 
speed  only  if  less  than  210  kns,  other- 
wise reduce  speed  to  210  kns  in  the 
hold.) 


HH  - Hold  Message  (No  direction 
specified) 


HRH  - Hold  right  turns 
HLH  - Hold  left  turns 
S - Single  symbol  fix  identification 
(d)  - Turn  change  rate  (see  Heading 

Function) 

Y - Automatic  descent  in  hold. 


Analysis 


Hold  capability  is  actually  a varia- 
tion of  the  Heading  Function.  Holding 
fix  cannot  be  specified.  When  message 
is  entered,  the  target  begins  holding 
at  its  present  position. 


Leg  length  may  be  specified  in  either 
minutes  or  miles.  00  in  the  leg  length 
will  result  in  360°  turns. 


Right  turns  will  occur  unless  an  (L) 
code  is  entered. 


Turn  rate  is  determined  as  described 
under  Heading  Function. 


Hold  capability  is  actually  a variation 
of  the  Heading  Function.  Holding  fix 
may  be  specified  by  entry  of  appropriate 
single  symbol  fix  identifier. 


Leg  length  is  fixed  and  is  not  variable. 
No  single  entry  will  automatically 
cause  360°  turns. 


Direction  of  turn  may  be  specified. 

If  not  specified  right  turns  will  occur. 


Turn  rate  is  determined  as  described 
under  Heading  Function. 
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J 


DYSIM 


ETG 


The  speed  of  the  target  will  be  reduced 
to  210  kns  (unless  current  speed  is 
less),  if  * is  not  entered.  A speed 
instruction  will  be  rejected  if 
entered  while  the  aircraft  is  in  a hold 

A hold  instruction  will  be  rejected  if 
the  aircraft  is  in  a turn. 

Altitude  of  the  aircraft  will  not 
change  in  a hold  unless  a separate 
altitude  instruction  is  entered. 


Speed  of  the  target  is  not  changed  in 
a hold  unless  a separate  speed 
instruction  is  entered. 


A second  message  is  available  which 
will  cause  automatic  descent  of  the 
aircraft  in  a holding  pattern. 


AUTOMATIC  FINAL  FUNCTION 

I 


Entry 


None 


(F15) ,TG,N,aaa,rrr .ENTER 
or 

(F15) ,TG,*, ENTER 


Legend 


N - Automatic  Final  Approach  Message 
aaa  - Airport  identification 
rrr  - Runway  identification 
* - Inhibit  target  termination  function. 


Analysis 


There  is  no  Automatic  Final  Approach 
capability  in  DYSIM.  


BLIP / SCAN , (dd ) , SFID,  ENTER 


BLIP /SCAN  FUNCTION 

I 

Entry 

None 
Legend 


(dd)  - Two  numeric  characters  identify-j 
ing  the  ratio  of  blips  to  primary  radar] 
scans. 


Analysis 


ARTS  III  does  not  process  primary  radar, 
and  therefore  does  not  have  this  function. 
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CODE  RELIABILITY  INDEX  (CRI)  FUNCTION 

I 

Entry 


CRI, (dd),SFID, ENTER 


Legend 


(dd)  - Two  numeric  characters  identify' 
ing  the  desired  index  of  reliability 


Analysis 


Mode  3A  validity  is  controlled  via  the 
Beacon  Function  in  ARTS  III 


SIM  START  FUNCTION 


Manual  Mode  Target 


START, ddd, TRACKBALL,  SAID,  ENTER 


(F15) ,TG,ddd ,ddd , etc.,  SLEW 


Automatic  Mode  Target 


START, (ddd) , (TRACKBALL) .SAID, ENTER 


Legend 


ddd  - Heading  in  degrees  (Manual  Mode)  ddd, ddd, etc.  - altitude,  speed,  etc. 
(ddd)  - Altitude  in  hundreds  of  feet 
(Automatic  Mode) 


TRACKBALL  - Slew  trackball  to  desired  Slew  - Slew  trackball  to  desired 

position  on  display  for  starting  this  position  on  display  for  starting  this 

target  and  enter  that  position.  target  and  enter  that  position. 


Analysis 


Manual  mode  requires  complete  target 
movement  control  by  the  pilot;  there- 
fore, heading  and  initial  position 
(trackball)  are  required.  Automatic 
mode  targets  will  move  in  accordance 
with  a defined  flight  plan;  and  there- 
fore, heading  and  initial  position  are 
not  required,  but  an  initial  start 
altitude  may  be  specified. 


There  are  no  flight  plans  in  ARTS  III, 
and  therefore  all  target  movements 
are  specified  by  the  pilot.  Initial 
altitude,  speed,  heading,  etc.  are 
included  in  tho  start  message. 


DYSIM 


ETG 


SIM  STOP  FUNCTION 


STOP, SF ID, ENTER 


(F15),TG, ENTER 


Analysis 


Sim  target  is  terminated 


Sim  target  is  terminated 


SIM  OFFSET  FUNCTION 


OFFSET, d.SFID, ENTER 


Legend 


d - A digit  (1-9) 


Analysis 


There  are  both  a Full  Data  Block  and  a There  is  no  simulation  data  block  in 


Simulation  Data  Block  in  the  enroute 
system.  The  Simulation  Data  Block  is 
offset  from  the  target  position  with 
this  message  in  accordance  with  the 
entered  code : 


ARTS  III  and  therefore  no  requirement 
for  this  function. 


1 - Northwest 

2 - North 

3 - Northeast 

4 - West 


6 - East 

7 - Southwest 

8 - South 

9 - Southeast 


5  - Current  Velocity  Vector 
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APPENDIX  E 


DATA  ENTRY  CONCEPT  DISPLAY 

The  format  of  the  displayed  data  used  for  the  touch-entry /menu  list  concept 
evaluation  is  shown  in  figure  E-l.  A list  of  active  aircraft  is  in  the  upper 
left  of  the  screen  arranged  in  ascending  alphabetical  and  numerical  order. 

Along  the  top  of  the  screen  are  abbreviated  column  headings  identifying  the 
items  required  to  be  continuously  available  to  the  simulator  pilot  (flight 
identification,  beacon  code,  speed,  altitude  and  heading).  A matrix  is  thus 
formed  which  portrays  all  required  information  on  active  aircraft  under  the 
pilot's  control.  Inactive  flights,  ready  for  activation,  are  listed  at  the 
lower  left.  At  the  middle  right  is  an  alphanumeric  keyboard  which  would  allow 
entry  of  numerical  data  or  data  to  be  spelled  out,  if  necessary.  At  the  lower 
right  is  a menu  list  area  for  a computer  generated  list  of  next  acceptable 
entry  data.  At  the  top  right  two  areas  were  set  aside:  one  is  a preview  area 
of  the  message  as  it  is  formed,  and  under  that  is  an  area  for  computer-generated 
messages. 

Entry  of  message  data  starts  with  a touch  on  the  desired  aircraft  identification 
(e.g.,  Continental  22,  in  figure  E-2).  The  result  is  a change  in  the  display  to 
isolate  the  selected  aircraft  identification  in  the  preview  area  and  portray  a 
list  of  possible  messages  in  the  menu  area  (figure  E-3).  The  operator  then 
touches  either  a message  from  the  menu  list  or  the  column  heading  depicting 
the  function  desired.  (In  the  latter  case,  a single  touch  of  the  desired 
item  in  the  matrix  opposite  the  desired  active  aircraft  identification  could 
replace  the  above  two  touches.)  Figures  E-2  through  E-7  depict  the  sequence 
of  displayed  pages  which  occur  as  a result  of  a simulator  pilot's  entries  when 
he  receives  the  following  clearance  from  a controller  trainee:  "Continental  22, 
turn  left,  heading  290."  The  circled  items  show  the  touch  required  after  the 
displayed  page  appears.  A touch  of  CLEAR  at  any  point  prior  to  entering  a 
message  deletes  the  message  composed  to  that  point,  and  returns  the  display  to 
its  original  page  without  any  message  sent  to  the  main  computer.  In  an  opera- 
tional system  the  ENTER  touch  at  the  end  would  cause  the  appropriate  DYSIM  or 
ETG  message,  as  translated  from  the  entered  data,  to  be  sent  to  the  main 
computer.  The  display  would  then  return  to  its  original  page.  In  this  case, 
the  heading  of  Continental  22  (C022)  would  then  increment  from  300  to  290 
as  the  target  in  the  main  computer  reacts  to  the  input  message.  For  the  demon- 
stration model,  the  display  returned  to  the  original  page  but  with  the  heading 
of  C022  changed  instantly  to  290. 


E-l 


BCON 


SPED 


ALTE  HDNG 


(PREVIEW) 


(ACTIVE  FLIGHTS) 


(COMPUTER  MESSAGES) 


ABCDEFG123 


HIJKLMN456 


OPQRSTU789 


V W X Y Z 


(MENU) 


(INACTIVE  FLIGHTS) 


CLEAR 


ENTER 


FIGURE  E-l.  DATA  ENTRY  CONCEPT  DISPLAY  FORMAT 
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400 
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300 
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330 

140 

240 

120 

190 
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130 

090 

180 

090 

135 

410 

330 

080 

ABCDEFG123 
HIJKLMN456 
OPQRSTU789 
V W X Y Z 0 


CLEAR 


ENTER 


FIGURE  E-2 . ORIGINAL  DISPLAY  OF  DATA  ENTRY  CONCEPT  EXAMPLE 
TOUCH  AIRCRAFT  IDENTIFICATION 


SFID  BCON  SPED  ALTE 


C022  2121  400 


350  300 


ABCDEFG123 


HIJKLMN456 


0PQRSTU789 


V W X Y Z 


START  SIM 


HANDOFF  ACCEPT 


DEPARTURE 


FLIGHT  PLAN  AMEND 


BLIP  SCAN 


CLEAR 


ENTER 


FIGURE  E-3.  DISPLAY  RESULTING  FROM  TOUCH  OF  C022  AIRCRAFT  IDENTIFICATION- 
TOUCH  FUNCTION  OR  MENU  LIST  ITEM  DESIRED 
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SFID 

BCON 

SPED 

ALTE 

HDNG 

C022  HEADING 

C022 

2121 

400 

350 

300 

ABCDEFG123 

HIJKLMN456 

OPQRSTU789 


BA  9 

V W X Y 

BN  2 

DL73 

EA75 

Qurn  leftm 

HA33 

TURN  RIGHT 

JL16 

DIRECT 

PA1 

INTERCEPT 

TS42 

HOLD 

TW58 

J 

CLEAR  ENTER 

FIGURE  E-4.  DISPLAY  RESULTING  FROM  TOUCH  OF  HEADING  FUNCTION  - TOUCH  ACTION 
DESIRED  IN  MENU  LIST 
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ALTE  HDNG 


C022  HEADING  TURN  LEFT 
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350  300 


ABCDEFG1©3 
HIJKLMN456 
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V W X Y Z ® 


TURN  LEFT 


TURN  RIGHT 


DIRECT 


INTERCEPT 


CLEAR 


ENTER 


FIGURE  E-5.  DISPLAY  RESULTING  FROM  TOUCH  OF  TURN  LEFT  ACTION-TOUCH  LIMITS 
OF  ACTION 


SFID  BCON  SPED  ALTE  HDNG  C022  HEADING  TURN  LEFT  290 

C022  2121  400  350  300 


ABCDEFG123 
HIJKLMN456 
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BN  2 
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EA75 

TURN  LEFT 

HA33 

TURN  RIGHT 

J116 

DIRECT 

PA1 

INTERCEPT 
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HOLD 

TW58 

CLEAR 


FIGURE  E-7.  DISPLAY  RESULTING  FROM  ENTRY  OF  MESSAGE  AND  CONSEQUENT  TARGET 
ACTION  - READY  FOR  NEW  MESSAGE 
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APPENDIX  F 

ENTRY  CONCEPT  EVALUATION  QUESTIONNAIRE  RESPONSES 
QUESTIONNAIRE 

ON  SIMULATOR  PILOT-GHOST  CONSOLE 


Name  Date 

Title 


How  familiar  are  you  with  radar  simulation  training  associated  with  the 
NAS  enroute  system? 

Not  at  all  IT  Somewhat  3T  Very  familiar  4E 

How  familiar  are  you  with  radar  simulation  training  associated  with  the 
ARTS  III  system? 

Not  at  all  IE  Somewhat  IT,  2E  Very  familiar  4T.  IE 

Have  you  actually  served  as  a "pilot"  in  radar  simulation  training?  5T,  4E 

We  want  to  evaluate  the  concept  of  data  entry  by  "menu"  lists  utilizing  a 
message-touch  system  for  use  by  pilot-ghosts  in  simulation  training.  The 
touch  equipment  being  used  here  is  a light  pen,  which  has  some  defects. 

We  would  use  a system  which  would  work  by  a touch  of  the  finger  on  the 
message  element  desired.  In  addition,  there  are  limitations  in  the 
computer  programming  done  so  far.  We  realize  that  it  is  difficult  to 
evaluate  a concept  without  also  evaluating  the  device  used  to  demonstrate 
that  concept,  but  we  ask  that  you  try.  Please  answer  the  following  questions 
in  order  to  help  us  evaluate  the  concept. 

NOTE:  T - Number  of  Terminal  ATCS  evaluators 
E - Number  of  Enroute  ATCS  evaluators 

| 


2 


Three  basic  measures  that  we  think  are  important  in  evaluating  any 
concept  are:  (1)  ease  of  learning,  (2)  speed  with  which  entries  can 
be  made,  and  (3)  error-proneness  in  making  entries.  Please  indicate 
below  the  response  that,  in  your  opinion,  is  most  appropriate  regarding 
pilot  entries  using  the  menu-list  and  message-touch  concept  in  response 
to  clearances,  as  compared  to  making  the  same  entries  using  ARTS  III 
or  NAS  consoles  and  keyboards. 

Greatly  Greatly  No 

Degrade  Degrade  Improve  Improve  Change 

HEADING  CHANGE 


Ease  of  learning 

2T,  IE 

IT,  3E 

2T 

Error-proneness 

4T,  IE 

3E 

Speed 

2T 

2T,  4E 

IT 

ALTITUDE  CHANGE 

Ease  of  learning 

IT,  2E 

IT,  2E 

3T 

Error-proneness 

3T,  2E  . 

2E 

IT 

Speed 

2T,  IE 

2T,  3E 

IT 

SPEED  CHANGE 

Ease  of  learning 

2T,  2E 

IT,  2E 

2T 

Error-proneness 

3T,  2E 

2E 

IT 

Speed 

2T,  IE 

2T,  3E 

IT 
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Greatly 

Improve 

Degrade 

Improve 

Greatly 

Improve 

No 

Change 

BEACON  CODE  CHANGE 

Ease  of  learning 

2T,  IE 

IT,  3E 

2T 

Error-proneness 

IT,  IE 

' 3E 

2T 

Speed 

2T 

4E 

2T 

SQUAWK  IDENT 

Ease  of  learning 

3T 

3E 

2T,  IE 

Error-proneness 

IT 

3E 

3T,  IE 

Speed 

IT 

2T 

4E 

IT 

DIRECT  TO  A FIX 

Ease  of  learning 

IT,  IE 

3T,  3E 

IT 

Error-proneness 

3T , IE 

IT,  3E 

Speed 

3T 

2T,  4E 

COMMENTS  ON  THE  ABOVE: 

(The  comments  emphasized  the  need  for  reduced  number  of  touches.  Some 
improvements  were  suggested.  The  concept  was  generally  praised.) 
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Additional  Menu  Lists 


The  use  of  menu  lists  is  being  considered  for  selecting  HEADING, 
ALTITUDE  and  SPEED,  instead  of  using  the  numeric  keyboard  for 
entering  these  values.  In  your  opinion,  how  will  this  affect: 


Greatly 

Degrade  Degrade 

Improve 

Greatly 

Improve 

No  Change 

Ease  of  learning? 

3T,  IE 

2T,  3E 

Error-proneness? 

IT,  IE 

2T,  3E 

IT 

Speed? 

2T 

3T,  4E 

Pilot  Capacity 

A "pilot"  will  be  able  to  handle 
a greater  3T,  4E 

fewer 

the  same  2T 

number  of  flights  using  a menu  list  device,  than  using  the  ARTS  III/NAS 
controller  console. 

Comment? 

(Comments  generally  were  in  support  of  the  belief  that  the  pilot  capability  would 
be  enhanced. ) 
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Training  Effect 

Some  of  the  training  benefit  gained  by  a developmental  controller  in  today  s 
system  by  acting  as  a pilot  may  be  lost  if  a special  pilot  device  is  imple- 
mented. The  training  benefit  that  will  be  lost  is 

significant  4T,  IE 

insignificant  IT,  3E 

Comment? 

(Comments  reflected  the  mixed  feelings  indicated  in  the  above  tabulation. ) 


We  believe  that  the  pilot  position  can  be  operated  efficiently  without  the 
use  of  a PPI.  Ghost  functions  (initiating  and  accepting  handoffs,  starting 
and  terminating  flights,  etc.  ) can  be  handled  with  a tabular  list.  Certain 
navigational  functions  that  presently  require  use  of  the  PPI,  such  as 
clearance  direct  to  a fix,  in  NAS,  can  be  accomplished , ‘ we  believe,  by 
means  of  software  in  the  pilot  mini-computer.  Also,  we  feel  that  pilot 
response  to  traffic  calls  can  be  arbitrarily  made.  Are  you  aware  of  any 
pilot  functions  that  require  a PPI  that  we  may  not  have  considered?  For 
example,  would  it  be  necessary,  even  in  the  future,  for  a pilot  to  follow 
other  traffic,  as  in  a visual  approach? 

Comment? 

(Comments  indicated  a decided  majority  (8  to  1)  felt  that  a PPI  (graphics) 
display  was  required  at  the  pilot  position.) 
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Can  you  suggest  improvements  to  the  data  entry  and  display  concept 
that  you  have  seen?  (Other  than  in  reference  to  the  light  pen  which 
we  won't  be  using,  anyway) 

(Many  suggestions  for  improvement  were  made  orally  at  the  debriefings. 
As  a result,  few  were  made  in  the  questionnaire.  Many  of  the  suggestions 
were  later  incorporated  in  the  pilot  console  specifications.) 


Please  comment  on  the  concept  of  menu-lists  and  a message-  touch 
system  for  a simulator  pilot  console,  particularly  with  regard  to  ease 
of  learning,  accuracy  of  data  entries,  and  speed  of  entries. 

(The  comments  were  generally  highly  favorable  towards  the  concept. 

The  need  for  portability  of  the  device  was  suggested  by  two  terminal 
controllers.  One  controller  suggested  that  the  pilot  console  be  "considered 
for  selected  facilities. . . rather  than  all  facilities.") 


APPENDIX  G 

AAF-600  LETTER  TO  ARD-100,  USE  OF  THE  DARC  PROCESSOR  WITH  PILOT  RESPONSE 
UNITS,  DATED  JANUARY  24,  1977 


DATE 


DEPARTMENT  OF  TRANSPORTATION 

FEDERAL  AVIATION  AP%*INISTRATION 


WASHINGTON,  .C.  20591 


IN  REPLY 
REFER  TO 


JAN  2 4 1917 

AAF-610 


subject  Use  of  DARC  Processor  with  Pilot  Response  Units 


.Av,i 

o'-  ••  ^ 

/ v r ■■ 


O V 
* 


T .'  * ! 

C T o / 


from  Chief,  Automation  Engineering  Division,  AAF-600 
to.  ARD-100 


As  agreed  at  the  briefing  on  the  pilot  consoles  presented  on 
December  7,  1976,  we  have  investigated  the  possibility  of  using  the 
so  called  "backup"  processor  in  the  DARC  system  as  the  processor  for 
the  pilot  consoles.  The  following  items  were  considered: 

* 

1.  The  DARC  system  design  has  not  been  finalized  and  we  do 
not  know  if  the  standby  processor  can  be  used  for  another 
purpose  without  impacting  DARC  system  performance. 

2.  The  Air  Traffic  Service  may  change  the  DARC  functional 
requirements  which  in  turn  may  change  requirements  for 
the  DARC  standby  processor. 

3.  There  are  other  offline  uses  which  have  been  proposed  for 
the  DARC  standby  processor,  such  as,  software  adaptation  and 
maintenance  printed  circuit  board  checking,  and  DCV-  testing. 
If  the  processor  is  available  for  offline  use,  these  other 
requirements  for  its  use  would  have  to  be  considered  along 
with  pilot  console  processing,  in  terms  of  priority  and  time 
sharing. 

4.  In  addition  to  using  the  DARC  standby  processor  for  the 
pilot  consoles,  all  of  the  DARC  peripheral  equipment  was 
requested.  Again,  we  could  not  agree  to  this  condition  until 
the  requirements  of  the  DARC  system  operation  are  defined. 


Since  it  was  indicated  that  a decision  was  necessary  by  January  1, 
we  must  take  the  position  at  this  time  that  tne  DARC  standby  processor 
should  not  be  considered  for  use  as  the  pilot  console  processor. 


a. 

L.  THOMPSON 
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GLOSSARY 


A3d2 
AAD-1 
AAF 
AAM 
AAT 
AED-1 
AFS 
APT 
ARD 
ARTCC 
ARTS  III 
ATC 
ATCS 
ATS 

CAMI 
CCC 
CD 
CDC 
CODE 
CRD 

DABS  Discreet  Address  Beacon  System 

DARC  Direct  Access  Radar  Channel 

DART  Data  Analysis  and  Reduction  Tool 

DCC  Display  Channel  Complex 

DEDS  Data  Entry  and  Display  System 

DG  Display  Generator 

DSF  Digital  Simulation  Facility 

DSS  Data  Systems  Specialist 

DYSIM  Dynamic  Simulation 

E&D  Engineering  and  Development 

EARTS  Enroute  Automatic  Radar  Tracking  System 

EPDO  Evaluation  and  Proviciency  Development  Officer 

EPDS  Evaluation  and  Proficiency  Development  Specialist 

ESI  Externally  Specified  Index  (Input  Control  Function  of  ARTS  III) 

ETG  Enhanced  Target  Generation 

FAA  Federal  Aviation  Administration 

FPL  Full  Performance  Level 

FSS  Flight  Service  Station 

GPI  General  Purpose  Input 

GPO  General  Purpose  Output 


Civil  Aviation  Medical  Institute 
Central  Computer  Complex 
Common  Digitizer 
Computer  Display  Channel 
Controller  Decision  Evaluation 
Computer  Readout  Device 


NAS  Enroute  Program  Tape  Designation 
Associate  Administrator  for  Administration 
Airway  Facilities  Service  (mail  routing  code) 

Office  of  Aviation  Medicine  (mail  routing  code) 

Air  Traffic  Service  (mail  routing  code) 

Associate  Administrator  for  Engineering  and  Development 
Airway  Facilities  Service 

Office  of  Personnel  and  Training  (mail  routing  code) 

Systems  Research  and  Development  Service  (mail  routing  code) 

Air  Route  Traffic  Control  Center 

Automatic  Radar  Terminal  Service  (Model  III) 

Air  Traffic  Control 

Air  Traffic  Control  Specialist 

Air  Traffic  Service 


GLOSSARY  (Continued) 


ICS 

IDA 

IOCE 

IOP 

M&S 

MDBM 

MLS 

MPX 

NAS 

NCP 

OJT 

OPT 

PAM 

PPI 

PVD 

QAK 

RKM 

RMIOC 

RNAV 

RTF 

5AR 

SRDS 

TRACON 

TSC 

USAF 

VFR 

VHF 

WVAS 


Integrated  Communications  System 
Institute  of  Defense  Analysis 
Input/Output  Control  Element 
Input/Output  Processor 

Metering  and  Spacing 
Multiplexed  Display  Buffer  Memory 
Microwave  Landing  System 
Multiplexer 

National  Airspace  System 
NAS  Change  Proposal 

On-the-Job  Training 

Office  of  Personnel  and  Training 

Peripheral  Adaptor  Module 
Plan  Position  Indicator 
Plan  View  Display 

Quick  Action  Keyboard 

Radar  Keyboard  Multiplexers 
Refresh  Memory  Input/Output  Control 
Area  Navigation 
Radar  Training  Facility 

System  Analysis  and  Recording 

System  Research  and  Development  Service 

Terminal  Radar  Approach  Control 
Transportation  Systems  Center 

United  States  Air  Force 

Visual  Flight  Rules 
Very  High  Frequency 

Wake  Vortices  Advisory  Services 
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